[Oorexx-rfes] [ oorexx-Feature Requests-1807250 ] Add support for resizable tokenized dialogs

[SourceForge.net <no...@so...>]

Feature Requests item #1807250, was opened at 2007-10-03 18:35
Message generated for change (Comment added) made by miesfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684733&aid=1807250&group_id=119701

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Classes
Group: v3.1.2
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: rffrexx (rfrasca)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add support for resizable tokenized dialogs

Initial Comment:
I create an oodialog script with a resizable dialog.  The script utilizes DlgAreaU.cls.  In source form, the resizing works perfectly.  After you tokenize the script, the dialog controls no longer resize.

It was explained to me that, the DlgAreaU class works by parsing the DlgObj that is used to instantiate the DlgAreaU object.  For this, it requires the source code, which I do not want to distribute.


----------------------------------------------------------------------

>Comment By: Mark Miesfeld (miesfeld)
Date: 2007-11-29 10:56

Message:
Logged In: YES 
user_id=191588
Originator: NO

Jon,

The solution I want to come up with is one where the resizing takes place
totally in the C code.  There are a number of optimizations you can do when
the resizing is done within the Window Procedure of the underlying dialog
itself.  Things you can't do when each resize event is relayed to ooRexx,
then ooRexx calculates the changes, then relays the resizing of each
control back to the OS.

In the ooDialog dialog, the user would specify constraints for all the
controls.  Like, say, for a button the constraint might be: never change
size x; never change size y; right edge stays absolute pixel distance from
right dialog border; bottom edge stays absolute pixel distance from bottom
diaglog border.  For a list control in the same dialog it might be no
constraint.  Then you would have a dialog where the button in the bottom
left corner would remain fixed to that position and the list box would grow
and shrink smoothly with the dialog.

Similar to what you said, the original size and position, and current size
and position of all the controls are stored.  But, they are stored in
structures in the C code, in the Window Procedure of the dialog.

I know how to do the C code part, what I haven't thought much about, yet,
is how to tie it into ooDialog.  I'm toying with the idea of adding an
attribute to the base dialog, say ~resizable that defaults to false.  Then
if the ooDialog user, early in the dialog creation cycle, changed the
attribute to true, the dialog would be made resizable, with all the
resizing handled by the C code.  The constraints for all controls would be
some default.  The ooDialog programmer could set contstraints for all
controls where the default was not satisfactory.

The problems / questions I can think of that I haven't put much thought
into, are things like:  what to do if the ooDialog programmer uses some of
the current methods that change size and position of the controls.  Should
you be able to change a dialog from non-resizable to resizeable after the
dialog has been displayed on the screen.  These are the types of things
that would make the implementation increasingly complicated.

It might be relatively simple to implement if you said okay you can have
resizable dialogs, but:

* you have to set the resizable attribute no later than the finish of
initDialog

* once set you can not change it

* once set you can not use the methods that manually change size and
position of the controls

* you have to set all constraints no later than the finsh of initDialog

That would probably fill the needs of 90% the dialogs people would want to
create.

----------------------------------------------------------------------

Comment By: Jon Wolfers (sahananda)
Date: 2007-11-28 13:37

Message:
Logged In: YES 
user_id=667060
Originator: NO

Hi Mark,

it does occur to me that if I was to try to do the resizing thing again I
would go about it differently.  Something along the lines of having a Table
of controls origional dimensions belonging to the baseDialog class, perhaps
adding IDs in the method ItemAdd.  There would then be no need to parse the
dialog definition.

I went the other way before because, 1) everyone believed at the time that
new users would have to familiarise themselves with defineDialog. 2) the
dlgArea & dlgAreaU classes were completely discrete from the extant
ooDialog classes.

I'd be really happy if you were to produce a solution that worked for
tokenized scripts and rc files.

Jon

----------------------------------------------------------------------

Comment By: Mark Miesfeld (miesfeld)
Date: 2007-10-03 19:02

Message:
Logged In: YES 
user_id=191588
Originator: NO

One of the things I want to do is create a true resizable dialog.

Jon's implementation is a very clever use of ooRexx and is a great
addition to ooDialog.  However, it does have some drawbacks. You can not
use it with a ResDialog or a RcDialog and as Robert has discovered you can
not use it with a tokenized program.

I haven't done any work on this as of yet, but I have been toying with the
idea of how to implement it.  I'm not sure when I can get to it, but it
won't be the near future. <grin>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684733&aid=1807250&group_id=119701