Hi Developers, there is an open bug https://sourceforge.net/p/oorexx/bugs/1647/ which was first reported nearly 5 years ago, in which use of some ooDialog public routines (ooDialog Ref 30.1.1) in some circumstances crash the interpreter.
I don't think that anyone has done any work on this, and it may be that because of it's special nature (Windows Gui programming) no one is going to. Please can I just initiate some discussion / ask some questions. *Firstly, the milestone for the bug ticket is 'ooDialog 4.2.0' - would this bug get more attention if the milestone was '5.1.0' - it does crash the 5.1.0 interpreter. Can I just change it?* I found myself able to recreate this problem reliably, and I might be wrong, but I have a hunch that the problem is in the use of the c++ function GetTextExtentPoint32, and I have another hunch that this problem only occurs with the 64bit interpreter (but not always). Calls to GetTextExtentPoint32 exist in several of the Public Routines (TimedMessage, InputBox, MultiInputBox, ListChoice, CheckList, SIngleSelection, Progress Dialog). They also exist in one of the ooDialog Main classes PropertySheet and it's long deprecated predecessor CategoryDialog Also they exist in the DynamicDialog mixin class used by all ooDialog programmers who do not use a resource builder. Luckily the calls there are in less used methods (createRadioButtonGroup, createCheckBoxGroup,CreateEditInput, createEditInputGroup, createEditInputStem, createComboBoxInput, createCheckboxStem & createRadioButtonStem) all of which simultaneously create a dialog control (or group of controls) and their static label(s). All of these channel through 19 calls to GetTextExtentPoint32 in one of [oodBaseDialog.cpp, oodControl.cpp, oodDeviceGraphics.cpp or oodialog.cpp] Now, I don't know enough about C++ or Windows GUI coding to understand the error, but I see the warning about runtime errors on this page https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-gettextextentpoint32w *So, I wonder: Even if we don't know how to fix this problem, could we not handle it such that it throws a rexx error rather than crashing the interpreter?* For myself, I have hit this problem in the InputBox and listchoice routines and have worked around it by writing my own safe routines. These require the size of the dialog to be specified at coding time rather than runtime, but as they are often used with static text labels this is not a big disadvantage. I could tidy these routines up and make them available in the sandbox as a workaround, but I don't want to do this if the bug is going to get attention, as no doubt my workarounds would then appear in users code and require support for decades. This leads me to ask the question: *Is anyone likely to fix this problem or handle the errors in the (near) future? *I'm not trying to pressure anyone, but a bit of crystal ball gazing might save us from me creating a future mess. thanks for listening Jon
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
