I guess IF you do want to show a dialog using the dialogs module in the onHide then you could use the scheduler plugin to call it. This would not interfere with the onHide code since it’s called from outside the onHide event. And since the JS thread is single threading the dialog have to wait in the queue until the onHide event is finished.
Of course this dialog can’t be used to give a user a choice to close or not. It’s just for showing a message.
So your code could look like this:
function onHideWindow(event) {
//The if statement checks if the onHide is called by the above method in which case it simply closes the FID.
//Otherwise it gives the users a warning message and cancels the closing of the FID. Fine in smart, not in web.
if(event.getElementName() == null && globals.g_trigger == 'btn_copyLoc') {
globals.g_trigger = null;
return true;
}
else {
}
plugins.scheduler.addJob("dialog_close_msg", new Date(Date.now()), globals.DIALOGS.showWarningDialog, 0, 0, null, ['Copy and Close!','Close this form by clicking the button ','OK']);
return false;
}
Thanks Robert and Johan. I do understand that I can PREVENT the closing of the window and now I understand how I can also give a dialog (JSWindow or modal_dialog) to tell the user why they can not shut the window by clicking the ‘X’. But would it ever be possible to have the ‘X’ button visibility as a property of the JSWindow itself so that the user never sees it at all? That would definitely be the cleaner way to go. Johan maybe that is what you mean when you say ‘currently just do:’. Does that mean that sometime we might get that visibility of the close button as a property? I can definitely work around it (and even more so now with your suggestions) but it would be really nice I think to have that property.
I didn’t read the whole thread, but what about if you try using the busy plugin in conjunction with the JSWindow? With the busy plugin you can block the user input - including preventing the user from closing the JSWindow until the method is finished. With the busy plugin you can grey out the form so that the user sees that he/she can not shut the window by clicking the ‘X’.
Again, I did not read through your issue/thread. Hopefully this helps.
Anyone who likes to have control over the visibility of this X control in dialogs I suggest you add your vote to the following feature request: https://support.servoy.com/browse/SVY-1292
You find the Vote option under the ‘More Actions’ button.
Thanks Robert I’ve done so! It seems infinitely simpler and more elegant for the developer and more intuitive for the user to have the visibility of the X control as a JSWindow property.
ROCLASI:
Anyone who likes to have control over the visibility of this X control in dialogs I suggest you add your vote to the following feature request: https://support.servoy.com/browse/SVY-1292
You find the Vote option under the ‘More Actions’ button.
I vote for it. +1.
I also suggest that someone open a new topic under the ‘Discuss Feature Requests’ section, so that those that did not check the Servoy 6.0.4 thread, can vote on the ‘X control in dialogs’ too.
I did something similar when David suggested better ways of flagging performance issues in this same post (Servoy 6.0.4). If you haven’t voted about this one, you can at this post: https://forum.servoy.com/viewtopic.php?f=8&t=17458)
But the voting should be done ON the ticket. See the link I provided.
I makes totally sense. I should have done the same thing with David’s idea.
I am not familiar with this ticketing system. I have a question. Why the ‘Affects Version/s’ is showing only ‘5.2.11’? Does this imply 5.2.11 and newer versions? See below:
Well that is the information that the submitter (in this case Donald J Lapin) put in. One can add multiple versions when needed. I don’t know if the engineers who handle the ticket will update it but I am sure they look if newer versions have the same issue.
In this case it’s a feature request so yes they will certainly merge any new features they put in an older branch into the newer branches.
jasantana:
I have also seen, that is since 6.0.3, that it is impossible to change the tabSequence of the inherited tabPanels, you cannot move them out of the sequence nor change it. Also the tabPanels added to the subclassed form, not the inherited, have a similar behaviour, you can only put them at the bottom of the sequence.
