This content has been marked as final. Show 5 replies
You can not customize the location of the Notes edit dialog.
Which version are you using?
20.2.0 centers it with respect to the applet window
I accept this answer however the UI is based upon java objects (AWT) and you can normally alter the location of a dialog using straight java API and seems a shame that the VueBean API does not allow the location to be moved.
Possible future enhancement maybe who knows.
For GUI objects which have not much complication, like information gui objects, you can use a custom action to add the gui a custom window. Then, replace the action with your custom action in the bin/Profiles/custom.gui file on the Autovue server. Not perfect method, since some system actions are called from more places than just the regular gui. Also, a laborious process, since there is no example around. But I customized completely the save dialog this way, though I had to drop import markups and some automated chain actions (like save all markups) still call the old dialog.
Still, the method is quite over-dimensioned to just get a position change... But I know no other way to do so.
I thought about doing this and the only thing that is making me stop is the fact when they double click on the note the 'old' dialog will pop up and not the new one created by me.
Do you have any example code to create a note silently? Also do you know how to override the double click event to use a new dialog?
I wonder if I could extent the MarkupNote and override certain functions to use my own dialog???
Like you say there are not many examples around.
My guess is that this behavior outside the basic gui file (in this case, the note window popping out a double click on a note) is what makes the manual to talk about adding custom actions, but not about replacing pre-existing ones. If all behavior in the gui truly came out of the gui file, these issues would not happen, but unfortunately that is not the case.
And unfortunately, I have no answer to workaround this. In my opinion, it would be a very welcome feature to have all actions mapped through the gui file, even those chained from sources other than an icon or a menu. This would probably be the less intrusive method for the current implementation.
Another method would imply a double check, where an enum of standard actions would be mapped against either core implementation or custom implementation. So, no matter where an action was called, if replaced this way, it would receive the proper calling. But it is up to Autovue's team to decide the direction to go here on future releases.