nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Browser fields deleted after save

System

This is driving me a little nuts...

When I save a DCR (with the DCT and JS files attached), the two browser elements revert to what they were before the DCR was saved. So, if it's a new record, they're blank. If it's an existing one, it reverts to what the value was previously.

The upload button on the DCT provides the user with a popup that allows them to browse for and upload a file, with a specified file extension, from their hard drive. This value then populates the browser element in the form which is is an alternative to importing to TeamSite and browsing from there. Also of note, the CallServer on this DCT checks to see if the DCR is a new one and if so, if there's another one with the same name that exists. If yes to both, it pops an alert and restricts the user from saving. This event also checks to see that the logged-in user is "allowed" to save/modify the DCR based on a configuration file elsewhere.

All of the other values in the form are saved successfully. However, the browser elements seem to want to revert.

Thanks,

Dave

Find more posts tagged with

Comments

Adam Stoller

This is driving me a little nuts...

When I save a DCR (with the DCT and JS files attached), the two browser elements revert to what they were before the DCR was saved.

Dave, is there a reason your DCT is using metadatacapture6.0.dtd in the DOCTYPE header?

No idea if that would cause the problem - but technically it's wrong.

Judging by the rest of the DCT - you're using datacapture5.0.dtd (not 6.0 - which requires 'location' and 'pathid' attributes')

Try fixing your DCT DOCTYPE reference and see if that fixes the other problem.

Migrateduser

Aah, good observation but that wasn't it. To clarify on my issue, the problem arises when I click on "Finish", not when I hit "Save" and changing the DTD did not help.

Misspoke -- yes, it also happens when I hit "Save".

Migrateduser

So, it seems that if I use the upload callout and it fills in the field for me, it's not being saved properly. However, when I type it in, it saves just fine. Below is the code that I suspect might be causing this problem. I don't think I'm doing anything strange -- the appropriate value is displayed in the DCT and everything.

[html]

myForm = eval("window.opener.top._dcWin.formframe.document.dcreditForm");
for (i=0;myForm.elements.length;i++) {
if (myForm.elements.name == '^ . $cgi->param('iw_callback_var') . qq^') {
myForm.elements.value = '/^ . $path . qq^/^ . $name . qq^';
break;
}
}
self.close();

[/html]

jbonifaci

Just out of curiosity, are you changing anything else in the form besides the file/upload path?

I know there used to be a bug where if the user didn't manually change any item, the form didn't recognize that any item was changed and therefore didn't save any of the values.

Try using your callout for the file item and then changing a different item manually and see if it saves both of your values then.

I had thought this was changed in a patch to always save every item regardless of whether the form thinks it has changed though. Maybe there's a setting?

I'm out of the office and don't have access to try anything out though, sorry.

Are you on the latest SP?

~Jeff

Adam Stoller

Dave - instead of doing it that way - I suggest you use the FormAPI method, where you get a handle on the FormAPI script layer and then use that to code in basic FormAPI accessors.
(numerous posts on-line and the FormAPI documentation covers this too).

As it is - the code you posted looks like a munged piece of javascript code with embedded perl-isms - so it's hard to tell you whether it should work or not.

Migrateduser

No, 6.5 SP1. I think I recall this bug but wasn't this a looooooong time ago? Like, way before 6.5 ever came out? Dunno... I'm

experimenting with a few things now so I'll follow up if I find anything.

To answer your question, I'm changing only this value in the form. Incidentally, the same script is called twice (as you can tell from the datacapture) and the script acts upon the respective field once it's called.

jbonifaci

I didn't actually look at your code, but how are you setting the value? If you're doing it the pre-formapi way, I suggest you change it to use formapi and .setValue(). It will likely recognize it as changed if you do it this way...

~Jeff

Migrateduser

I looked at your attachment. Where is the "/iw/scholastic/util/js/intranet.js" file. The attachment only has "landing.js". Hard to troubleshoot without the whole thing.

Migrateduser

I left that out intentionally as it has no relevance to this issue. Personally, I find it more difficult to troubleshoot when I'm faced with too much information.

Migrateduser

Sure enough, it was my antiquated DOM method of setting the value and not FormAPI. It just shows that one's own legacy code deserves attention and update once in a while!

Thanks, fish and Jeff.