Dave Williss | 2 Jun 00:16 2004

Form geometry weirdness

I've encountered a weirdness in layout of a form under some
specific circumstances.  The problem seems to be in geometry_manager()
in Form.c.  If there is a request to change both the height and width but
only
one can be changed then this function is returning XtGeometryNo, but it
seems that _XmMakeGeometryRequest() expects it to modify the reply
to say what it _would_ accept and return XtGeometryAlmost.

Changing the final return to ..

    return (good == 0) ? XtGeometryNo : XtGeometryAlmost;

Is part of the solution.  However, the values filled into the reply seem to
be
returning the opposite of what _XmMakeGeometryRequest is expecting.
There's some code that looks like this...

    if (Wants(CWWidth))
    {
        ask++;
        if ((mr.request_mode & CWWidth) && mr.width == request->width)
        {
            good++;
            reply->request_mode &= ~CWWidth;
         }
    }

If we return XtGeometryAlmost, then _XmMakeGeometryRequest will call us a
second time, but if we've masked out the changes that we'll accept then the
2nd
(Continue reading)

Dave Williss | 2 Jun 00:26 2004

Re: Exporting functions from DLLs in Windows

After doing a little more research into .def files, it appears we could
use one to export all of the functions.  However, according to the
MSDN documentation...

"Note that when you export a variable from a DLL with a .def file, you do
not need to specify __declspec(dllexport) on the variable. However, in any
file that uses the DLL, you must still use __declspec(dllimport) on the
declaration of data."

So in other words, we may only need to add the XMLIBEXPORT to
the variables like xmArrowButtonWidgetClass.  And we'd still have to
create a file listing all the functions to export.

Still a pain, but maybe less pain than adding an XMLIBEXPORT line
to every function and vairable that needs to be exported..

----- Original Message ----- 
From: "Dave Williss" <dwilliss <at> microimages.com>
To: "Danny Backx" <danny.backx <at> skynet.be>
Sent: Tuesday, June 01, 2004 9:25 AM
Subject: Re: [Lesstif] Exporting functions from DLLs in Windows

> The XMLIBEXPORT gets defined to be either  __declspec(dllimport)
> or __declspec(dllexport) (or just exern if not compiling on Windows)
>
> When building the library,  dllexport tells the compiler/linker
> to actually make the symbol visible outside the dll.  Without it, its as
> if the entire dll is one module and all the functions are static.
> You can accomplish almost the same thing as dllexport by creating a
> .def file which lists all the functions to export and passing that to the
(Continue reading)

Danny Backx | 2 Jun 00:35 2004
Picon

Re: Exporting functions from DLLs in Windows

There's stuff in scripts/OS2 which Alexander wrote to do
similar things for OS/2.

Can it be reused ?

	Danny

On Wed, 2004-06-02 at 00:26, Dave Williss wrote:
> After doing a little more research into .def files, it appears we could
> use one to export all of the functions.  However, according to the
> MSDN documentation...
> 
> "Note that when you export a variable from a DLL with a .def file, you do
> not need to specify __declspec(dllexport) on the variable. However, in any
> file that uses the DLL, you must still use __declspec(dllimport) on the
> declaration of data."
> 
> So in other words, we may only need to add the XMLIBEXPORT to
> the variables like xmArrowButtonWidgetClass.  And we'd still have to
> create a file listing all the functions to export.
> 
> Still a pain, but maybe less pain than adding an XMLIBEXPORT line
> to every function and vairable that needs to be exported..
> 
> ----- Original Message ----- 
> From: "Dave Williss" <dwilliss <at> microimages.com>
> To: "Danny Backx" <danny.backx <at> skynet.be>
> Sent: Tuesday, June 01, 2004 9:25 AM
> Subject: Re: [Lesstif] Exporting functions from DLLs in Windows
> 
(Continue reading)

Dave Williss | 2 Jun 16:06 2004

Re: Exporting functions from DLLs in Windows

Ah! very good!  I didn't know to look there.  One of the files is basically
the .def file that you'd use.  Microsoft's linker complains about not
understanding
some of the directives, but they're just warnings.  That reduces the problem
to one
of adding the XMLIBEXPORT thing in front of variable exports only.  MUCH
less
pain.

----- Original Message ----- 
From: "Danny Backx" <danny.backx <at> skynet.be>
To: "Dave Williss" <dwilliss <at> microimages.com>
Cc: "LessTif Mailing List" <lesstif <at> lesstif.org>
Sent: Tuesday, June 01, 2004 5:35 PM
Subject: Re: [Lesstif] Exporting functions from DLLs in Windows

> There's stuff in scripts/OS2 which Alexander wrote to do
> similar things for OS/2.
>
> Can it be reused ?
>
> Danny
>
> On Wed, 2004-06-02 at 00:26, Dave Williss wrote:
> > After doing a little more research into .def files, it appears we could
> > use one to export all of the functions.  However, according to the
> > MSDN documentation...
> >
> > "Note that when you export a variable from a DLL with a .def file, you
do
(Continue reading)

Dave Williss | 2 Jun 16:51 2004

More problems

Our testers have found a few more problems in Lesstif which
I will be tracking down.  
 
1. Modal dialogs aren't modal.  Anybody have any idea where
    to look to fix this one?  The dialog is created via XmCreateFormDialog
    and is supposed to be FULL_APPLICATION_MODAL
 
2. I have a "wizard" dialog that changes it's contents when you
    click a "next" button.  The content change causes the dialog
    to resize.  With Lesstif, once it resizes, it resized again and
    again, slowly growing by one pixel each time.  It's really bizarre
    and only happens on one of our dialogs.  I suspect that it may
    be related to the other resize problem I found yesterday.
 
 
 -- Dave Williss
------
Meddle not in the affairs of dragons,
   for you are crunchy and taste good with catsup
Michel Bardiaux | 3 Jun 11:51 2004
Picon

Re: More problems

Dave Williss wrote:

> Our testers have found a few more problems in Lesstif which
> I will be tracking down.  
>  
> 1. Modal dialogs aren't modal.  Anybody have any idea where
>     to look to fix this one?  The dialog is created via XmCreateFormDialog
>     and is supposed to be FULL_APPLICATION_MODAL

ISTR I had to introduce a kluge in my code when using Lesstif; 
basically, the WM_TRANSIENT_FOR property is not correctly set. The 
kludge involved adding a handler for StructureNotifyMask on the dialog; 
in the handler:

	if (XtIsRealized(w) && XtIsManaged(w) && event->type == MapNotify) {
		XtVaGetValues(XtParent(w), XmNtransientFor, &tfw, NULL);
		XSetTransientForHint(XtDisplay(w), XtWindow(XtParent(w)), XtWindow(tfw));
		XtRemoveEventHandler(w, StructureNotifyMask, 0, toolbar_popup_handler, 
client_data);
}

HTH, but it was on a rather old version of Lesstif, the problem it 
attacks may have been fixed since then, so dont hold your beath! Use 
xprop to check.

>  
> 2. I have a "wizard" dialog that changes it's contents when you
>     click a "next" button.  The content change causes the dialog
>     to resize.  With Lesstif, once it resizes, it resized again and
>     again, slowly growing by one pixel each time.  It's really bizarre
>     and only happens on one of our dialogs.  I suspect that it may
>     be related to the other resize problem I found yesterday.
>  
>  
Sorry, no idea here.

HaND,
--

-- 
Michel Bardiaux
Peaktime Belgium S.A.  Bd. du Souverain, 191  B-1160 Bruxelles
Tel : +32 2 790.29.41
Dave Williss | 3 Jun 16:48 2004

Re: More problems

Well, after several hours of debugging and tracing, I managed to fix
the modal dialog issue.  Then I went to make some diffs to send in my
patches.  I decided to pull down the latest daily snapshot to make my
diffs against and discovered that somebody had already fixed my problem!

I don't suppose there's a list I could subscribe to that would send me the
CVS commit comments, is there?  If there was, I might have saved myself
some time.  On the other hand, tracing through this was a great learning
experience.

My other problem with a dialog growing seems to be something silly
one of our programmers did.  When he gets a resize event on the dialog,
he resizes some widgets in the dialog rather than using a form to do it
for him.  But resizing the widgets causes the dialog to grow by 2 pixels,
so he gets a resize event and repeat.  The fact that resizing the widgets
causes the dialog to grow again is may or may not be an error in Lesstif.
But at any rate, we can fix it in our own code.

----- Original Message ----- 
From: "Michel Bardiaux" <mbardiaux <at> peaktime.be>
To: "LessTif Mailing List" <lesstif <at> lesstif.org>
Sent: Thursday, June 03, 2004 4:51 AM
Subject: Re: [Lesstif] More problems

> Dave Williss wrote:
>
> > Our testers have found a few more problems in Lesstif which
> > I will be tracking down.
> >
> > 1. Modal dialogs aren't modal.  Anybody have any idea where
> >     to look to fix this one?  The dialog is created via
XmCreateFormDialog
> >     and is supposed to be FULL_APPLICATION_MODAL
>
> ISTR I had to introduce a kluge in my code when using Lesstif;
> basically, the WM_TRANSIENT_FOR property is not correctly set. The
> kludge involved adding a handler for StructureNotifyMask on the dialog;
> in the handler:
>
> if (XtIsRealized(w) && XtIsManaged(w) && event->type == MapNotify) {
> XtVaGetValues(XtParent(w), XmNtransientFor, &tfw, NULL);
> XSetTransientForHint(XtDisplay(w), XtWindow(XtParent(w)), XtWindow(tfw));
> XtRemoveEventHandler(w, StructureNotifyMask, 0, toolbar_popup_handler,
> client_data);
> }
>
>
> HTH, but it was on a rather old version of Lesstif, the problem it
> attacks may have been fixed since then, so dont hold your beath! Use
> xprop to check.
>
>
> >
> > 2. I have a "wizard" dialog that changes it's contents when you
> >     click a "next" button.  The content change causes the dialog
> >     to resize.  With Lesstif, once it resizes, it resized again and
> >     again, slowly growing by one pixel each time.  It's really bizarre
> >     and only happens on one of our dialogs.  I suspect that it may
> >     be related to the other resize problem I found yesterday.
> >
> >
> Sorry, no idea here.
>
> HaND,
> -- 
> Michel Bardiaux
> Peaktime Belgium S.A.  Bd. du Souverain, 191  B-1160 Bruxelles
> Tel : +32 2 790.29.41
>
> _______________________________________________
> Lesstif mailing list
> Lesstif <at> lesstif.org
> https://terror.hungry.com/mailman/listinfo/lesstif
Dave Williss | 3 Jun 17:23 2004

Minor comiple error.

Another minor patch...

FileSB.c, line 1962 has a function declared as...

    static inline Boolean
    FileIsHidden(String name)
    {
        ...

Microsoft's compiler will let you specify static or inline, but not both

I took out the "inline", but you could just as easily take out the "static"
and it would compile either way.

 -- Dave Williss
------
Meddle not in the affairs of dragons,
   for you are crunchy and taste good with catsup
Danny Backx | 3 Jun 18:37 2004
Picon

Re: More problems

On Thu, 2004-06-03 at 16:48, Dave Williss wrote:
> Well, after several hours of debugging and tracing, I managed to fix
> the modal dialog issue.  Then I went to make some diffs to send in my
> patches.  I decided to pull down the latest daily snapshot to make my
> diffs against and discovered that somebody had already fixed my problem!
> 
> I don't suppose there's a list I could subscribe to that would send me the
> CVS commit comments, is there?  If there was, I might have saved myself
> some time.  On the other hand, tracing through this was a great learning
> experience.

Yes there is : lesstif-commits. The website shows how to
subscribe. Here is an excerpt from http://www.lesstif.org/lists.html :

LessTif Public Mailing Lists 
lesstif <at> lesstif.org is the list for general discussion of LessTif. 
Visit https://terror.hungry.com/pipermail/lesstif/ to subscribe. 

lesstif-commits shows CVS commits (and is therefore read-only). 
Visit http://lists.sourceforge.net/lists/listinfo/lesstif-commits to
subscribe. 

Mailing list archives 

Both lesstif and lesstif-commits/ are archived online. 

  
--

-- 
Danny Backx - danny.backx-at-skynet.be
Dave Williss | 3 Jun 22:12 2004

Yet another form geometry problem

I have another geometry problem in Forms.

Say you have three nested forms.  
The outer form (call it A) has, from top to bottom,
some widgets, another form (call it B), and some
more widgets. Form  B contains form C, which
is initially not managed when everything else is.
When the user selects some option, form C gets
managed.  Form B does all its geometry stuff and
resizes itself just fine.  However, it seems that at
least in some cases, when B resizes itself, it doesn't
cause A to resize and move its children out of the way.

The dialog that they're all in does get resized to the
size it would need to be, but form A (which is a
child of the dialog shell) doesn't redo its layout 
accordingly.

Any clues?

 -- Dave Williss
------
Meddle not in the affairs of dragons, 
   for you are crunchy and taste good with catsup

Gmane