Occasionally in Designer, I am getting strange behaviour where when I load up the form, all of the @field@ placeholders are replaced with the text which was there in Preview mode before.
I thought this was previously caused when I saved the while still in Preview mode but now the behaviour seems sporadic.
Please advise - is this a known issue?
NB: This has been seen across versions and installations.
Do you happen to have these problematic items set with a class named âdynamicâ?
I donât believe so - it seems to happen to the entire document in one go.
Itâs dangerous as you donât notice whilst continuing to develop on Preview mode for layout purposes, you save the file and then realise youâve lost all of your placeholders.
It is a known issue, unfortunately, an inconsistent one, that we have yet to reproduce at will in order to find the source and fix it.
I suggest you open a technical support call through our website. This way we can compile example of the problem and try to pinpoint the source. It would greatly if you can remember what you where doing the last time it happened or better, being able to reproduce it at will.
Thank you. I will have one of my colleagues update the thread - he has seen this most recently and will be able to tell you if there is any repeatable behaviour which causes it.
Iâll also put a ticket in with local support to get it recognition in the JIRA world.
J
As jim3108 said, I had this happen to me today. Iâm not sure exactly what triggered it, as I was working on a different part of the form, but when I looked back all of my @tag@ had been replaced with the actual data, rather than the @tag@ variable. Unfortunately Iâd saved since it happened, and made enough changes that I was unable to just revert back, and so had to go through where all of the @tag@ should have been and call them again properly.
For the job Iâm working on, each div just has a different @tag@ within, placed around a PDF background. I havenât deliberately set anything to dynamic, when I go to Preview mode it does assign each < div > as âspan .ol_wrapped .dynamicâ.
However there was no effect on the recurring items that I had within a detail table, they werenât affected by this.
Hi hamelj,
I thought I reported this issue before or at least mentioned it to one of OLâs employees. The only way I can reproduce it 100% is when you go into preview mode and copy/paste a positioned box. After that the new div will have the value of the field and not the @field@ when going back to design mode.
If you look at the source code after this happens there is no difference in the code. However when you click on the original divâs text in preview mode, the text has a class called ol_wrapped dynamic. The newly created div that is now âbrokenâ does not have a class.
Hope this is somewhat useful.
Regards,
S
I think this is because of the class dynamic. It has been reported already but I will do a follow-up on this.
If any other way to reproduce the behaviour are found, please post it here or open a technical support ticket through our website.
I have reported the similar behaviour to our R&D.
Hi hamelj,
I just found another way to trigger this. Iâm using the same script on multiple sections and wanted to add the reference number to another section. So I place a positioned box while in preview mode and added the @field@ and ID to it. Once the ID was in and I clicked elsewhere for it to apply, the placeholder immediately changed to the fields value. When going into Design mode the value of the field remained and it did not revert back to @field@. I hope this slightly different approach helps.
On a different topic. Did you know you can have multiple divâs with the same ID and they all work on a single section/page. Is this dangerous?
Regards,
S
@Sharne: the HTML spec states that all IDs throughout a page must be unique. However, we decided not to enforce that rule (just like many browsers donât enforce it either) because many HTML coders and sites use duplicate IDs on purpose (most obvious example being YouTube - check out how many <div id-"button" âŚ> there are on the main page!).
Plus, enforcing it would require Connect to constantly monitor what youâre typing/pasting and notify/prevent you whenever you duplicate an ID, which I have a feeling would quickly become a PITA and might hinder performance.
I personally donât think thereâs ever a good reason to use duplicate IDâs but since the technique is being used and might be expected of Connect, we canât prevent it from happening.
Hi Phil,
I was just wondering because Connect does enforce unique IDâs. When having a div with an ID and trying to add another div and giving it the same ID Connect gives an error that reads âMust be uniqueâ. However to circumvent that one can copy a div and then the duplicate IDâs are ok. Hence why I thought it could be a bug.
Donât get me wrong, I like to duplicate as it reduces the amount of scripts be it text or standard.
Regards,
S
Yep, sorry, I should have been more clear for other readers who might happen upon this post: Connect does in fact prevent you from using duplicate IDs through the GUI, but it will let you do whatever you want if you work directly in the HTML source code.
Thanks for pointing this out.