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

*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

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

Oorexx-devel mailing list

Reply via email to