XForms: fdesign(87.5):alignment,sizing problems

Ivan Powis (pczip@chemistry.nottingham.ac.uk)
Fri, 07 Nov 1997 11:50:11 GMT

To subscribers of the xforms list from Ivan Powis <pczip@chemistry.nottingham.ac.uk> :

Having been using the latest fdesign distributed with 87.5 (for hp)
I have encountered some odd behaviour when using fdesign to edit
existing fd files.

First, although the counter on the alignment form now remembers any
value set in a previous session, the non-default value shown in the
counter does not actually appear to be the one in effect when fdesign
starts up ie as best I can tell its actually using the default of 10
until I change the counter, when the value used does seem to catch up
with the indicated value.

Secondly, I have encountered the mysterious 'form resizing bug' in a
multi-form fd project - or at least something like this previously
reported problem. Specifically I find that when changing to the second
form it can sometimes appear shown in a downsized window, with just
the topleft corner of the form visible. The reduced window won't
resize _unless_ I increase the value of the alignment counter (!). I
can then drag the window frame out to expose more of the underlying
form. Sometimes I get so far like this, but need to click the
alignment counter and drag resize again to get back to the original
size. Also it seems like if I immediately reselect the first form
without resizing the second one, then it too can get shown in the
default sized window. I believe I can consistently reproduce this
resizing behaviour with HPs VUE3.0 manager (but not with other WMs)
_if_ the alignment value is set less than 5 when I make the
switch. Some interaction between the window manager and the alignment
setting giving this problem?

The third point is more just an observation on a potential problem. I
notice that using the menu initialisation feature now in fdesign
causes it to generate a static FL_PUP_ENTRY array to hold the
initialisation with a name which appears to be generated by prepending
menu_ to the menu label. Now if in a multi-form fdesign project there
are two or more forms each having a menu with the same label (eg File,
Help, Options ...) this will lead to conflicting declarations of the
FL_PUP_ENTRY arrays (menu_File[] menu_Help[] menu_Options[] ...).
Might it be better to generate names for the FL_PUP_ENTRY from the
menu name rather than its label (since I have more freedom to choose
distinct names than labels) or -better- by appending the form name
also (eg menu_File_frm1[]) ?? Since it is a static object there is
only a need to worry about name conflicts within the prog_fd.c file
and such a change shouldn't break anything already out there.


___ ___/ _ __ / Ivan Powis TEL: +44-115-951-3467 |
/ / / Department of Chemistry FAX: +44-115-951-3562 |
/ / _/ University of Nottingham |
/ ___/ Nottingham NG7 2RD |
/ / UK |
/ / pczip@chem.nott.ac.uk |
_______/ ____/ http://www.chem.nott.ac.uk/IP.html |

To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuf2.usuhs.mil or see
Xforms Home Page: http://bragg.phys.uwm.edu/xforms
List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/