[MiNT] Dialogs in windows
Szymanski, Frank-Peter
I have a little problem with a GEM-application I wrote with gcc 2.9.x and
Interface 2.33.
There is a form lying in a window. Whenever I move this window everything is
fine when it is topped. When it is lying in the background and topped again
I get a rectangle of the part of the window I have to redraw.
Unfortunately when the window is lying in the background and moved it gets a
WM_REDRAW message but when I try to get the rectangles I have to rewrite I
get some real funny results.
Imagine my window lying in the middle of the screen and another window is
lying above it in the lower right corner of the window of my application.
So my window is divided into three parts. The upper half of the window is
free. The lower half is divided into two parts. The left hand side is free
while the right hand side is hidden by another applications window.
Then I move my application to the left of the desktop (not up). But instead
of getting just the lower left part of my window so I can redraw it, I get
both "free" parts of my own window.
This is the code I wrote:
static void redraw_mywindow( short my_window, short x, short y, short w,
short h )
{
GRECT r;
short w1, w2, w3, w4;
/* is window topped?
/* then redraw rectangle
wind_get( my_window, WF_TOP, &w1, &w2, &w3, &w4 );
if( window == w1 )
{
wind_update( BEG_UPDATE );
wind_get_grect( my_window,
WF_WORKXYWH,
&r );
/* this is my infodialog that should be redrawn
infodialog->ob_x = r.g_x + 2;
infodialog->ob_y = r.g_y + 2;
infodialog->ob_width = r.g_w - 4;
infodialog->ob_height = r.g_h - 4;
objc_draw( infodialog, ROOT, MAX_DEPTH,
x,
y,
w,
h );
wind_update( END_UPDATE ); /* Fenstererneuerung beendet */
}
else
{
/* only redraw the part of the window that is not hidden */
wind_get( my_window, WF_FIRSTXYWH, &w1, &w2, &w3, &w4 );
while( w3 && w4 )
{
wind_get_grect( my_window,
WF_WORKXYWH,
&r );
printf( "x: %i y: %i w: %i h: %i\r\n",
w1,
w2,
w3,
w4 );
printf( "r.g_x: %i r.g_y: %i, r.g_w: %i, r.g_h: %i\r\n",
r.g_x,
r.g_y,
r.g_w,
r.g_h );
wind_get( my_window, WF_NEXTXYWH, &w1, &w2, &w3, &w4 );
}
}
}
Any hints?
I also played around with windom but unfortunately when I want to use this
library it seems to me that I have to rewrite a lot of code of my
application (AppInit() instead of app_init() etc.) so finally I decided not
to use windom.
Are there any other libraries that are just enhancements of the gemlib so I
can stay with my old source and just do some extensions?
Regards,
Frank
Frank Naumann
> Are there any other libraries that are just enhancements of the gemlib so I
> can stay with my old source and just do some extensions?
You can take a look on the cflib.
Tschuess
...Frank
--
ATARI FALCON 040 // MILAN 060
-----------------------------------------
http://www.cs.uni-magdeburg.de/~fnaumann/
e-Mail: fnau...@freemint.de
Konrad Kokoszkiewicz
> window is lying above it in the lower right corner of the window of
> my application.
>
> So my window is divided into three parts. The upper half of the
> window is free. The lower half is divided into two parts. The left
> hand side is free while the right hand side is hidden by another
> applications window.
>
> Then I move my application to the left of the desktop (not up). But
> instead of getting just the lower left part of my window so I can
> redraw it, I get both "free" parts of my own window.
As far as I understand the problem and as far as I can remember, this is up
to the AES, what rectangles are to be redrawn. If the window is bottomed and
partially overlapped by another window, I am afraid then, that the AES would
decide that all rectangles are to be redrawn. This at least looks so on
N.AES 2.0. So there is nothing bad in the fact that the AES tells your
application to redraw the parts which are already drawn. Of course, this
perhaps could act more intelligent way, but ...
> This is the code I wrote:
>
> static void redraw_mywindow( short my_window, short x, short y, short
> w, short h )
> {
> GRECT r;
>
> short w1, w2, w3, w4;
>
> /* is window topped?
> /* then redraw rectangle
>
> wind_get( my_window, WF_TOP, &w1, &w2, &w3, &w4 );
>
> if( window == w1 )
> {
> wind_update( BEG_UPDATE );
If I can have any (irrelevant to the problem you described) comment here:
you should not divide the redrawing routine into two cases, this should be
the same regardless of whether your window is topped or not. At least, in a
multitasking system, after your wind_get(WF_TOP) and before the 'if'
statement, preemption can occur, another application can do something else,
and as a result your window can be no longer on top, right? So when the
scheduler gives the next turn to your application, the result you check with
the 'if (window == w1)' can be no longer valid and you get mess on the scree
n.
CVV
--
Konrad M.Kokoszkiewicz
http://draco.atari.org
** Ea natura multitudinis est,
** aut seruit humiliter, aut superbe dominatur (Liv. XXIV,25)
*************************************************************
** Taka to juz natura pospólstwa, albo sluzalczo sie plaszczy,
** albo bezczelnie sie panoszy.
Szymanski, Frank-Peter
> remember, this is up to the AES, what rectangles are
> to be redrawn. If the window is bottomed and
> partially overlapped by another window, I am afraid then,
> that the AES would decide that all rectangles are to be
> redrawn.
> This at least looks so on N.AES 2.0. So there is nothing
> bad in the fact that the AES tells your
> application to redraw the parts which are already drawn. Of
> course, this perhaps could act more intelligent way, but ...
Actually I am using N.AES 2.0. The problem is that the rectagle I get with
wind_get_grect( my_window,
WF_WORKXYWH,
&r );
is the rectangle that was overlapped but when the window is not topped this
is the rectangle that is overlapped by another application so my application
gets a WM_REDRAW message and overwrites the part of the window of the other
application. Although it looks quite funny it is not what the user expects.
:-)
> > This is the code I wrote:
> >
> > static void redraw_mywindow( short my_window, short x,
> short y, short
> > w, short h )
> > {
> > GRECT r;
> >
> > short w1, w2, w3, w4;
> >
> > /* is window topped?
> > /* then redraw rectangle
> >
> > wind_get( my_window, WF_TOP, &w1, &w2, &w3, &w4 );
> >
> > if( my_window == w1 )
> > {
> > wind_update( BEG_UPDATE );
>
> If I can have any (irrelevant to the problem you described)
> comment here:
> you should not divide the redrawing routine into two cases,
> this should be the same regardless of whether your window
> is topped or not.
> At least, in a multitasking system, after your
> wind_get(WF_TOP) and before the 'if' statement,
> preemption can occur, another application can do something
> else, and as a result your window can be no longer on top,
> right?
> So when the scheduler gives the next turn to your application,
> the result you check with the 'if (window == w1)' can be no
> longer valid and you get mess on the screen.
Thanks for your advice. You are right. I forgot about that. Aniplayer is one
of the candidates who would produce such an effect.
Perhaps someone has some more multitasking friendly code at hand?
Regards,
Frank
Szymanski, Frank-Peter
>> enhancements of the gemlib so I can stay
>> with my old source and just do some extensions?
> You can take a look on the cflib.
I thought Christian Felsch dropped development decades ago. Is it still
maintained by someone?
Regards,
Frank
Frank Naumann
Sure, it's in the FreeMiNT CVS repository:
http://sparemint.atariforge.net/cgi-bin/cvsweb/lib/cflib
Szymanski, Frank-Peter
> >
> > I thought Christian Felsch dropped development decades ago.
> Is it still
> > maintained by someone?
>
> Sure, it's in the FreeMiNT CVS repository:
>
> http://sparemint.atariforge.net/cgi-bin/cvsweb/lib/cflib
Seems to me that this is what I was looking for.
Although it's quite interesting to program dialogs in windows with just the
gemlib my goal is to provide some useful applications to the ATARI
community. So every minute I save with the cflib is a minute I can spend on
the application itself.
Regards,
Frank
Standa Opichal
Hi! There is also much higher level library http://windom.sf.net (LGPL)
developed and constatly beeing improved. Check it out, you don't need to
mess with the low level AES stuff.
best regards
STan
Konrad Kokoszkiewicz
add a comment to my answer to Frank's e-mail, replied to myself instead of
the list. Also - when I was replying to Franks original post - I replied
first directly to him instead of the list. I wonder how much of such mess it
costs each month.
Lonny Pursell wrote:
> I managed to lose the post, but my "C" isn't so good anyway.
> One thing that is easy to forget, with dialogs rendered in windows,
> you must adjust the root object's x/y position to that of the window's
> work area just prior to rerendering the rsc in the window.
> Otherwise you get some strange results.
Konrad Kokoszkiewicz
> with
>
> wind_get_grect( my_window,
> WF_WORKXYWH,
> &r );
>
> is the rectangle that was overlapped but when the window is not
> topped this is the rectangle that is overlapped by another
> application so my application gets a WM_REDRAW message and overwrites
> the part of the window of the other application. Although it looks
> quite funny it is not what the user expects. :-)
I see. So the result you get from the wind_get_grect() is quasi reverse to
the one that is expected?
Henk Robbers
Hi
I have rewritten your example as attached.
As Draco pointed out, the FIRST/NEXT_XYWH loop gives you all the
visible rectangles. This is usefull if you want to update your
window contents yourself.
On a WM_REDRAW you must intersect all the rectangles with the
rectangle of the WM_REDRAW message.
This reduces the amount of repainted area considerably.
--
Groeten; Regards.
Henk Robbers. mailto:h.ro...@chello.nl
http://members.ams.chello.nl/h.robbers/Home.html
Interactive disassembler: TT-Digger; http://digger.atari.org
A GEM replacement for MiNT: XaAES; http://xaaes.atari.org
A Home Cooked teXt editor: AHCX
The free desktop: TERADESK
Henk Robbers
Oops.
I have used 2 kinds of rectangle types. {Bloody copy/paste ;-)
Oh well, its the mechanism what its about.
Lonny Pursell
> Yet another result of the "no changes to Reply-To" policy: Lonny wanting to
> add a comment to my answer to Frank's e-mail, replied to myself instead of
> the list. Also - when I was replying to Franks original post - I replied
> first directly to him instead of the list. I wonder how much of such mess it
> costs each month.
>
> Lonny Pursell wrote:
>
>> I managed to lose the post, but my "C" isn't so good anyway.
>> One thing that is easy to forget, with dialogs rendered in windows,
>> you must adjust the root object's x/y position to that of the window's
>> work area just prior to rerendering the rsc in the window.
>> Otherwise you get some strange results.
For the life of me I keep forgetting to edit the darn reply to.
I'm on several mailing lists and this is the only one that requires
fussing around with the reply address. Thanks Draco for reposting my
reply although I don't think it was much help. ;-)
--
Lonny Pursell http://www.q1.net/~atari/
Konrad Kokoszkiewicz
> I'm on several mailing lists and this is the only one that requires
> fussing around with the reply address.
The same here.
By the way, your program for editing the mint.cnf file has a bug: it assumes
that all the settings are in the mint.cnf file. However, they can also be
spread in other files, which are included to the mint.cnf by the 'include'
directive. So on my system the program warns me about non-defined something,
while this thing is perfectly defined, just not in the mint.cnf itself.
Szymanski, Frank-Peter
> http://windom.sf.net (LGPL)
> developed and constatly beeing improved. Check it out, you
> don't need to
> mess with the low level AES stuff.
I also did some tests with this library but unfortunately it seems that I
have to complete rewrite my application to benefit from this library. That
was not my intention. Maybe next time when I write a new ATARI application
from scratch. :-)
Regards,
Frank
Szymanski, Frank-Peter
> http://sparemint.atariforge.net/cgi-bin/cvsweb/lib/cflib
Seems to me that this is exactly what I was looking for. I did a few tests
with it and it seems to be a great library. I keep you informed at the
beginning of next week when I did more tests during the weekend.
Regards,
Frank
Szymanski, Frank-Peter
thanks for your help. Although I try to use cflib I will also give your
suggestions a try this weekend.
Regards,
Frank