One of the persistent errors going from 8.5 to 8.5.1 is that documents no longer go into edit mode on a XPage. I presume this is because of the previously described event handler change, since going to edit mode is an event on a link. Here’s what’s there:
I’ve manually cleaned and recompiled every single XPage and Custom Control in this application, yet it the above code remains and it will not go into edit mode.
Any suggestions? Thanks for your time…
EDIT:
If I use the “Events” tab to re-define the link event to go to edit mode, it re-generates exactly the same code, bollixing my formatting in the process. Another manual clean and full build has no effect.
I can edit the same Ticket in the Notes client without issue. It’s only the XPage that’s borked.
Subject: I don’t know how to get into contact with you except here, Paul…
However, I’ve have always, always seen incorrect URLs on hover. Even today I am searching for a way to debug what code on an automagic button is doing (automagic being something the XPage generated using a simple action, as opposed to an URL I build manually). Each and every single button in my application shows precisely the same URL on the status bar when I hover, yet each and every single button performs a completely different action when it’s clicked. All of the buttons appear to do what the eventHandler specifies. None of the buttons show what that may be.
In my instance, I have an onunload function that clicks a button if the user navigates away from the page. I know this is fraught with peril, but I see no alternative to ensure code runs if the user, say, clicks Back on the browser instead of a button. I’m attempting to determine how to get that ononload function to skip the button click under predetermined circumstances, so if the page is unloading “normally” it won’t attempt to run the code. To facilitate this, I have an alert in the programmatic button click function that tells what it’s clicking. This alert always shows precisely what hovering on the automagic buttons shows: the current XPage URL.
For example, I’m editing a document. The browser address bar shows:
Every single button on the XPage shows the URL above on the status bar when I hover over it, even though many of them do completely unrelated things when clicked.
The programmatic click function’s alert shows the above URL as what’s being “clicked”, even though that programmatic click performs the function that the button does. In my example it’s simulating the user clicking the “Cancel” button, and based on the server console, even though “alerts” the above URL when run, it performs the “Cancel” button function.
This makes it utterly impossible to debug any button or button action on a XPage, because what’s shown and what’s done have zero relation to each other.
Should I submit a PMR for this? Maybe it’ll get assigned to you (grin)…
Subject: XPage edit document not working – different scenario
Like David, I also experienced this. My scenario was a little different. Mystified me for too long until the brain kicked in, so thought I’d post in case others hit this too.
My XPage [Edit] button was using a simple action to change the document mode to Edit and doing a Full Update. It wouldn’t go into edit mode when I clicked the button, but if I edited the URL from “openDocument” to “editDocument” the document was put into Edit mode.
I removed all custom controls (none had any editable areas on them but did it anyway as per Paul’s response here). Still wouldn’t go into Edit mode when I clicked the [Edit] button but field validation kicked in and one of my fields failed the validation so was kicking up an error. I had created the document initially via the Notes client so not all of my fields were perfect as per the XPage validation.
Once I checked the option “Do not validate or update data” on the [Edit] button simple action, the document properly went into Edit mode when I clicked the [Edit] button. Maybe if I had disabled ClientSideValidation on the control in question, the changing into Edit mode might’ve worked properly with my initial [Edit] button action.
This issue doesn’t happen all the time or more correctly it doesn’t happen with every scenario where the change document mode simple action is set.
What I’m seeing happening is that this issue can be reproduced if you have a XPage that contains a custom control and this custom control contains an editable area. And into this custom control you have another custom control with an editable area. Regardless of where the action is it will fail and you have to click the action twice in order for it to work.
If you have say this change document mode on say a XPage then that’ll work or event on the first custom control. But this fails when you used a nested custom control
When I hover over the edit button, which explicitly says to enter edit mode, the automagic URL on the status bar says “action=openDocument&documentID=…”. This is incorrect. If I click the Edit link, then change “open” to “edit” on the URL, it edits the document just fine.
It’s good to know at least the system isn’t messing up … it’s opening (not editing) the document precisely like it’s told to.
It’s bad that the automagic is hosed. It’s hard to get much more explicit than “<xp:changeDocumentMode mode=“edit”></xp:changeDocumentMode>”.
Actually all the links seem to be completely messed up. When it edit mode, the Edit link is replaced by “Save” and “Cancel” links. In either read or edit there are other links present as well. No matter what mode, read or edit, the document happens to be in, the status bar for all links simply shows the current URL.
But when I click the links, they do something utterly different than they show. This is bizzare, and makes it impossible to troubleshoot why a given link is not working. Edit is hosed. Save works. Cancel is hosed. Other links work or not apparently randomly, yet each and every link shows, on the status bar, exactly the URL in the address bar.