[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] wind_set(WF_TOPMOST) extension



søn, 30,.04.2006 kl. 18.48 +0200, skrev olivier.landemarre@utbm.fr:
> Quoting Odd Skancke <ozk@atari.org>:
> 
> >  Hi,
> >
> >  I have just checked in my first implementation of WF_TOPMOST. I think
> > the test applications work as expected, but it would be nice to get some
> > feedback from you who know how it should work :)
> 
> If you send me directly xaaes binary, I try to test it.

 I can send you a binary, ofcourse. If you already have an XaAES
installation, what do you have installed? 

> 
> I have just to see a bug for this part in myaes unfortunatly :-(

 Oh..

<-snip->

> > >
> > > In fact this function can be usefull for application.
> > > One is simply for add a long value link to window, there is no interact
> > with
> > > aes, this is for user only, for example to put pointer link to window.
> >
> >  Ah, I see. Is this available to applications yet? And is there a name
> > for this mode yet?
> No absolutly no because I have not put any documentation for this, this is add
> only in first time for internal use, and as I think it could be usefull, I just
> put it.
> 
> #define WF_USER_POINTER 230
> 
> long is pass in wind_set() with p1 and p2
> 
> wind_get() return value in intout[1] and intout[2]
> 
> >
> > > Second is to have a child window (only one at this time), when link a
> > window to
> > > an other window, if mother window is close, link window is close, and if
> > this
> > > have itself a link window of course it close etc.
> >
> >  Sounds like a good idea actually. This is up and working in MyAES now?

> Yes of course for a very long time (since hierarchical menu are implemented
> because I use it internaly for this)

 Hmm... isnt it dangerous to use it internally while it is accessible
'from the outside'? Isnt it harder to maintain this?

> > What is the function name, if any?
> 
> #define WF_WIND_ATTACH 231
> 
> in p1 there is the number of the window to attach to the target window design
> 
> wind_get() return in intout[1] if there is the window attach
> and in intout[2] if target window is itself an attach window the window on wich
> it is attach, 0 of course for a standard window

 This attachment, is it related to the open/closed status of the parent
window? I mean, the window(s) attached this way will be slaves of the
parent window when closing/opening(), right? Incase this is to be
extended later, perhaps it would be a good idea to indicate what kind of
attachment one wants by selecting this;

wind_set(handle, WF_WIND_ATTACH, phandle,type,0,0)

 where handle is the handle of the window to attach to phandle, and type
is bitmask indicating attach-links, For example OPEN(1), FOCUS(2), etc.
Just an idea.



 Best Regards,
Odd Skancke