I’ve tried the “ZetaOne” wrapper to move the dialog to the correct place in the DOM. When I do that, it gets an Exception that the id for the widget it’s creating is already registered, and the dialog fails. I even put in a check for the dialog before calling the wrapper to run destroyRecursive, but that makes no difference. I consistently get an Exception and see no dialog.
The Exception doesn’t appear until I click the button that should present the dialog, because the dialog doesn’t exist until the button is clicked.
From what I understand of dojo dialogs, one makes div with an id, puts markup under that div to lay out the dialog, tells dojo to treat that div as a dialog by passing the id to dialog_create(), then one my use the id to get a reference to the dialog as needed. So if I change the id of the div (or remove it entirely), how do I get a reference to the dialog later?
-
If I use the “ZetaOne” wrapper but change the ID, I get a blank dialog. It’s got a title and a "X’ to close it, but no content. I’m thinking this is because there’s no longer a reference to the div that defines the content. The “X” also does nothing and I have to kill the window to “exit” the dialog.
-
From Luc’s post here I’ve also tried a plain dijit.Dialog() constructor. This creates the dialog just fine, using exactly the same ID that gets an exception above. But while I see the dialog and may interact with it, the “Add Comment” button does nothing but dismiss the dialog, just like Cancel. It never runs any CS or SS, no simple action, nothing, or at least a breakpoint in Firebug never stops in the CS button code, and an alert in the CSJS does not pop. Yet the code to dismiss the dialog, when the dialog button is clicked, is IN the CSJS. If it’s not running that, how does it dismiss?
-
In a comment on the Xpages Blog, “Dragon Chow” has the same issue on April 29. Buttons are not working in a dialog. The code (s)he presents there is similar to one of the many variants I’ve tried, except I’m using an id: instead of an url:. I also run this code on a button directly, instead of doing it on load, because a companion page to the above has a working sample of this dialog in action, and that sample calls this code on a button, then destroys the dialog when dismissed.
-
I’ve actually tried it both ways. If I do addOnLoad, it gets an error on page load that that mll is not a function. If I breakpoint in the onload function and single step I get no such error, but when the function exits the browser constantly shows the “busy” cursor and no buttons work anywhere. “Back” on the browser window itself does, so the browser isn’t locked up. Just the CSJS appears to be.
-
I have also captured the sample code from the working sample page, and the full HTML source of the working sample page, to use as a model. So far that’s not been much. The sample runs, my code doesn’t. Other than removing the partial refreshes, because I’m not using them, one of the many variants I’ve tried is identical to the sample, both with and without references to non-existent elements like editDocumentRegion. All variants of the “ZetaOne” wrapper produce the same id collision error.
-
I’m thinking the straight create renders because the dialog is “outside” the DOM, so there’s no collision, but it fails to run anything server-related because it’s “outside” the DOM, and the XPage doesn’t know what to do.
-
I’m thinking the “ZetaOne” wrapper doesn’t render because it’s “inside” the DOM tree and there is a collision with the (dialog) div’s ID attribute, but I don’t know how to resolve that. I’m hoping since it is “inside” the DOM tree, server-side things will work, if I can only get to where the dialog is usable.
-
Could someone who’s done this successfully please toss me a bone?
Thanks for your time…
Subject: bump → Still not working…
Subject: Have you seen this post
Does this help you?
Subject: Thanks David…
- I have tried this, and it doesn’t work for some reason. I’m not doing a pick list, but the concept is similar:
-
Create a custom control to define the dialog content. I have done it both with and without a panel to enclose the custom control, though this web site shows it with that panel. Currently I do not have a panel enclosing my custom control … the control itself has the panel as the first element, and I use that panel’s ID to create the dialog.
-
Use dijit to display it. I have used four different styles of CSJS, including one identical to the code here, which explicitly moves the dialog to the Form tag. I have also used addOnload() to pre-create the dialog, and created it on-the-fly. Currently I do not pre-create the dialog with XSP.addOnLoad(), I create the dialog on-fhe-fly as Jeremy does on the XPages Blog, but unlike Jeremy who puts the dialog under Body, I am putting it under Form.
- But I can change it to be like this quite easily. Even though I’m certain I’ve done it before, I’ll be happy to try it again. Who knows? This might be “The Time”.
Thanks for your suggestion…
Subject: Dialogs…
I’m not going to pretend to be an expert on this… cause I’m really not. 
But I did get a dialog working in on of my applications. I’m doing everything on a custom control. so no custom control for the actual dialogbox. I’m pretty sure I didn’t even try that… so I don’t know if there’s an issue. I’m NOT doing a picklist either. I’m just basically displaying a window to show more details for a document.
If I remember right I think the key for me ended up being that I needed to call a partial refresh from CSJS before the dialogbox. Probably because I’m pulling in data for it and needed that data to be refreshed. Here’s that little bit of code.
XSP.partialRefreshPost(“#{id:myPanel}”);
dijit.byId(“picklistdialog”).show();
Does this help at all or not really?
I’m going to try and do a demo on dialogbox in a, hopefully soon, Notes In 9 (notesin9.com).
Subject: Dunno, I’ll give it a go and see. Thanks!..
Subject: same error message (Dialog into a repeat control)
Hi, i receive the next error message when submitting:
“Tried to register widget with id=…:0:DialogBox but that id is already registered”
Data is saved first time, but after page update, i receive that error message.
The Dojo Dialog DIV tag is into a repeat control, and that repeat control is into a partial update area.
A save document button into that repeat control is who start the partial update…
Did you fix the problem??
Thanks
Diego
Subject: It seems like your error is not the same as mine…
-
I finally hacked a solution by unloading the page each save. Since it would reliably work on the first save and only the first save, what I did set a sessionScope variable to what that save should have done, then load a different page entirely. That page would check the sessionScope variable to see if an action was required, and it if was required, it would perform that action using an AJAX call. If that AJAX call resulted in an error, it would then reload the previous page to show the user the error and allow resolution.
-
It was an ugly reverse polish kludge, but it did provide a consistent, repeatable event sequence that WQS used to trivially accomplish, and XPages would not do under any circumstance.
-
This was using 8.5.1 FP1 HF472, that exact version being the only one at deployment time that would actually keep attachments on resaving a page. I haven’t had the opportunity to sample the runWithDocumentContext() call in 8.5.2 in this application, and I don’t see how I ever will, so I can’t say if that would make it work or not.
Subject: I’ve done it with Dojo samples.
I’ve copied/pasted sample code from this site into script blocks.
http://www.dojotoolkit.org/reference-guide/dijit/Dialog.html#dijit-dialog
They work fine, although the style sheet needs to be set to make it look nice.
Subject: Thanks Simon. But how do you get it to save?
- I managed to get it to present the dialog, using either “plain” markup (as the page you refer to, which I used as a model), or using xp:.. automagic markup (using the xpagesblog sample as a model). But it won’t run any server-side actions, ie, won’t work. Or it does work. One time and one time only. Here’s the scenario:
-
User clicks button.
-
Buttons presents dialog.
-
User enters data, selects from a drop down, etc. In this instance I’m confining myself to one text area and one text area only.
-
If user accepts, put data in a known field and save the document. This runs postSaveDocument, which runs an Agent, which runs piles of legacy code based on the value of the known field.
-
If the Agent indicates success, we’re done. One save is all we need.
-
If the Agent indicates failure, reload the current page with a message in panel. At this point the user could do any number of things, including return to step 1.
Whatever the user does, after step 6, they will most likely save the document a second time, which should trigger postSaveDocument a second time, which should run the legacy code a second time. But it doesn’t. After the first invocation, postSaveDocument will not run again on that page, until it’s completely unloaded (as in navigate to another page entirely) and reloaded. Then it will run postSaveDocument once, until the next reload, and so on.
-
I changed it to use the xp:... automagic markup so I could move the <xp:saveDocument /> action into the dialog itself, instead of attempting to pass a value back from the dialog to tell the invoking button whether to continue or not. This is how it’s done on the xpagesblog site sample, and it seemed like it should be less hassle to do it that way. Alas that did nothing at all … under no circumstances would it trigger or run any code, client or server side, under the xp:eventHandler tag directly on the dialog. Ever.
-
To get it to run a save at all I had to use the xpagesblog trick of running a server-side event from client side code. A “simple” <xp:saveDocument /> on the dojo dialog button simply would never trigger.
-
This thread:( ) is similar to the current one, but contains different information, including relatively current source. The primary difference between that source and what I have now is that the “Add Comment” button does not have an xp:eventHandler, it has onclick=“dlgWFNSubmit()”, and it runs the following client-side code:
function dlgWFNSubmit() {
var xpAct=dojo.byId("#{id:xpAction}");
xpAct.value="WFN:"+dojo.byId("#{id:dlgWFComment}").value+"]";
dijit.byId('#{id:dlgWFNote}').hide();
executeOnServer("saveOnly");
alert("Ran: \""+xpAct.value+"\"");
return true;
}
The “executeOnServer()” function is a literal cut and paste from here:
So I still don’t see how what is supposed to be trivially simple functionality can go so horriby awry. If you could theorize on that I’d be happy to hear what you come up with.
Subject: The dialog is under the body tag, that’s not right is it?..
-
I installed the EventBug extension to FireBug, and logged clicks on the Accept Button for one of my dialogs. When I look at the event in the log and follow the parent links back up the chain, it ends at . If I’m not mistaken in order to function correctly a dijit dialog has to be under .
-
I’m currently using the “ZetaOne wrapper”, which looks like it should be automagically putting the dialog under , but it doesn’t seem to be putting it there based on the event chain.
-
Actually Jeremy’s own dialog_create() has this line:
dojo.body().appendChild(dialogWidget.domNode);
which should move under after ZetaOne’s constructor puts it under . That implies is the right place for it.
Is this in the right place?..
EDIT:
Even when I replace the body setting above with this:
dojo.query(‘form’, dojo.body())[0].appendChild(dialogWidget.domNode);
the event still shows as being under the body.
-
My surmise on this dialog issue is the dialog is improperly placed in the DOM tree, so the XPage doesn’t always know how to handle the dialog event. I could be wrong, however, because even when it fails, it runs querySaveDocument, so the XPage knows that something needs to be done. It’s simply not running postSaveDocument.
-
I have a PMR open on this, and have had for months. So far all I’ve gotten is that dojo is a third-party product and Lotus doesn’t support it, so I’m swinging in the breeze. Yet Lotus appears to have no other suggestion for a dialog on a XPage. I’d really appreciate any input…