Speaking to a few of the users of the Truss Plugin it still seems I have issues with Mac users when it comes to the WebDialog menus, the show_modal method does not work correctly and does not block the code which creates all sorts of havoc.
I am wondering if the newer HtmlDialog finally resolves this issue for MacOS, if so I would like to switch to the newer UI system even though it will probably break the plugin for all users of older version of SU.
“modal” was never that on the Mac with regard to UI::WebDialog windows. I think the explanation was that on MacOS “modal” means it always stays on top of the other windows of the application to which it belongs. This is a MacOS policy, that discourages “blocking” windows.
But in the MS Windows realm, “modal” means that it blocks, and there are two kinds, “system modal” and “application modal”.
I believe that the intent is yes, show_modal is meant to be “application modal” on both platforms.
But John ( @john_drivenupthewall ) or Steve ( @slbaumgartner ) should weigh in on whether the goal was met.
Use branching code ie: if defined?(UI::HtmlDialog)
Module, Class and Method definitions can be nested inside if … else … end blocks that are evaluated at load time and provide variable definitions based on an expression (in this case the existence of a class.)
You can also define a constant reference that variably points at the class object needed …
Somewhere around here I posted and example of a cross-class get_element_value() method.
EDIT: For the asynchronous working example see …
What some coders do is define a wrapper class that has common method names, that calls the appropriate method in whichever dialog class is used. (Needed because for some reason yet unexplained, they chose slightly different method names in the newer dialog class, which has complicated converting code to use the newer class.)