1. xControls How To
I have a control (a child window) in a window. I want
the bottom of that window to follow the bottom of the
parent window, up to and not beyond a certain size.
Is there a way to control that with xControls? I've tried
using LimitSize with Geometry and can't seem to make
it work like I want. grrrrr.
-=ck
"Programming in a state of EUPHORIA."
2. Re: xControls How To
> I have a control (a child window) in a window. I want
> the bottom of that window to follow the bottom of the
> parent window, up to and not beyond a certain size.
> Is there a way to control that with xControls? I've tried
> using LimitSize with Geometry and can't seem to make
> it work like I want. grrrrr.
>
> -=ck
> "Programming in a state of EUPHORIA."
Ooo, thats a tough one... lemme poke it around some on my system
and I will see what I can come up with.
Just the bottom? Dont touch the child windows width?
Don Phillips - aka Graebel
National Instruments
mailto: eunexus @ yahoo.com
3. Re: xControls How To
> > I have a control (a child window) in a window. I want
> > the bottom of that window to follow the bottom of the
> > parent window, up to and not beyond a certain size.
> > Is there a way to control that with xControls? I've tried
> > using LimitSize with Geometry and can't seem to make
> > it work like I want. grrrrr.
> >
> > -=ck
> > "Programming in a state of EUPHORIA."
>
> Ooo, thats a tough one... lemme poke it around some on my system
> and I will see what I can come up with.
>
> Just the bottom? Dont touch the child windows width?
Hows this? Child is a constant 200 pixels...
If the parent window is 300 pixels or less, it will stick to the bottom;
otherwise it will be a constant height as well...
At least I think this is what you were looking for...
-=-=-=-=-=-=-=-=-=-
without warning
include Win32Lib.ew
include xControls.ew
constant
main = create( Window, "", NULL, 0.25, 0.25, 0.5, 0.5, 0 ),
ID1 = create( Window, "", main, 0, 0, 0, 0, {WS_CHILD,WS_VISIBLE} ),
GMID = xControl( Geometry, "", main, 0, 0, 0, 0, 0, 0 )
manage( GMID, ID1, {0,5}, {0,5}, {ID1,200}, {1,-5} )
procedure ModifyWinColors( integer self, integer event, sequence parms )
setWindowBackColor( ID1, #FF0000 )
end procedure
setHandler( main, w32HOpen, routine_id("ModifyWinColors") )
-- dynamically set child window to sticky only when below a certain height
procedure DynamicWindow( integer self, integer event, sequence parms )
sequence Rect
integer Height
Rect = getClientRect( self )
Height = Rect[4] - Rect[2] - 10 -- (10 is the extra two 5 spacings around the
child)
if Height > 300 then
-- constant
manage( GMID, ID1, {0,5}, {0,5}, {ID1,200}, {ID1,300} )
else
-- sticky
manage( GMID, ID1, {0,5}, {0,5}, {ID1,200}, {1,-5} )
end if
end procedure
setHandler( main, w32HResize, routine_id("DynamicWindow") )
-- force an initial resize
VOID = invokeHandler( main, w32HResize, {0,0,0} )
WinMain( main, Normal )
-=-=-=-=-=-=-=-=-=-
Don Phillips - aka Graebel
National Instruments
mailto: eunexus @ yahoo.com
4. Re: xControls How To
Don wrote:
>
> > I have a control (a child window) in a window. I want
> > the bottom of that window to follow the bottom of the
> > parent window, up to and not beyond a certain size.
> > Is there a way to control that with xControls? I've tried
> > using LimitSize with Geometry and can't seem to make
> > it work like I want. grrrrr.
>
> Ooo, thats a tough one... lemme poke it around some on my system
> and I will see what I can come up with.
>
> Just the bottom? Dont touch the child windows width?
Right. There's another control to the right of it whose width
is dynamic, but this one's width is static.
-=ck
"Programming in a state of EUPHORIA."
5. Re: xControls How To
Don wrote:
> Hows this? Child is a constant 200 pixels...
> If the parent window is 300 pixels or less, it will stick to the bottom;
> otherwise it will be a constant height as well...
>
> At least I think this is what you were looking for...
Yes, exactly! Now, can it be incorporated directly into the
xControls library?
-=ck
"Programming in a state of EUPHORIA."
6. Re: xControls How To
> > Hows this? Child is a constant 200 pixels...
> > If the parent window is 300 pixels or less, it will stick to the bottom;
> > otherwise it will be a constant height as well...
> >
> > At least I think this is what you were looking for...
>
> Yes, exactly! Now, can it be incorporated directly into the
> xControls library?
Hmm, no I dont think so. xControls is supposed to be as generic as
possible and this is quite specific. Plus adding in this kind of
functionality is A) quite easy as it is and B) would muddy up the
control creation syntax wise.
I would just cut and paste the above routine right in your program
as is. Of course, if a lot of people start screaming about this I
will of course try and support it.
Don Phillips - aka Graebel
National Instruments
mailto: eunexus @ yahoo.com
7. Re: xControls How To
Don wrote:
> > > Hows this? Child is a constant 200 pixels...
> > > If the parent window is 300 pixels or less, it will stick to the bottom;
> > > otherwise it will be a constant height as well...
> >
> > Now, can it be incorporated directly into the
> > xControls library?
>
> Hmm, no I dont think so. xControls is supposed to be as generic as
> possible and this is quite specific.
What about something like this:
manage( GMID, win_Floor, {0,4}, {0,224}, {win_Floor,164}, {1.0,-5} )
manage( GMID, win_Floor, {0,4}, {0,224}, {win_Floor,164}, {win_Floor,132} )
This would apply a variable height relative to the parent control,
up to a maximum of 132. Or use a supplement...
manage( GMID, win_Floor, {0,4}, {0,224}, {win_Floor,164}, {1.0,-5} )
manage_max( win_Floor, 0, 132 ) -- width, height
This enhances the library in a logical way.
> Plus adding in this kind of
> functionality is A) quite easy as it is
IMO, this goes against the purpose of the xControls library, which is
to automagically manage sizes and positions without having to use
extra code.
> and B) would muddy up the
> control creation syntax wise.
Using the above syntax, I don't think it muddies it.
> I would just cut and paste the above routine right in your program
> as is.
Yes, it works fine!
> Of course, if a lot of people start screaming about this I
> will of course try and support it.
Thanks, Don! IOU. :)
-=ck
"Programming in a state of EUPHORIA."
8. Re: xControls How To
> What about something like this:
>
> manage( GMID, win_Floor, {0,4}, {0,224}, {win_Floor,164}, {1.0,-5} )
> manage( GMID, win_Floor, {0,4}, {0,224}, {win_Floor,164}, {win_Floor,132} )
>
> This would apply a variable height relative to the parent control,
> up to a maximum of 132.
Hmm. I dont see how this would work as stated above. To me there seems
to be a conflict. You will notice that:
{win_Floor,164}, {win_Floor,132}
Both of these look exactly alike so how can it be determined that you
mean dynamically sticky instead of a constant height?
> Or use a supplement...
>
> manage( GMID, win_Floor, {0,4}, {0,224}, {win_Floor,164}, {1.0,-5} )
> manage_max( win_Floor, 0, 132 ) -- width, height
>
> This enhances the library in a logical way.
I do agree with this. If I do decide to add this in it would be either
this way or devise a completely new syntax for the creation with backwards
compatibility.
> > Plus adding in this kind of
> > functionality is A) quite easy as it is
>
> IMO, this goes against the purpose of the xControls library, which is
> to automagically manage sizes and positions without having to use
> extra code.
Actually I disagree with this. Its intended purpose is to give people a
simple interface to do simple windows management. The fact that it can
also handle some complex management is a bonus. It is not (and was not)
intended to be an "end all" solution. If it beyond the scope of this
library to handle, it is probably complicated enough to warrant hard
coding...
> > and B) would muddy up the
> > control creation syntax wise.
>
> Using the above syntax, I don't think it muddies it.
No, actually it doesnt. The main reason I am hedging on this is that
at the moment, the code is short, sweet, and to the point. Its a very
basic loop which can run very fast with a minimal of overhead and almost
no conditional branching. Which I actually find amazing considering
how flexible it is.
Basically it gets down to adding something like this would require alot
of conditional checks and code. While it would make your application
smaller and easier to read, for anyone not actually using this kind of
window they would suffer a performance hit.
> > I would just cut and paste the above routine right in your program
> > as is.
>
> Yes, it works fine!
>
> > Of course, if a lot of people start screaming about this I
> > will of course try and support it.
>
> Thanks, Don! IOU. :)
9. Re: xControls How To
Don wrote:
>
> > What about something like this:
> >
> > manage( GMID, win_Floor, {0,4}, {0,224}, {win_Floor,164}, {1.0,-5} )
> > manage( GMID, win_Floor, {0,4}, {0,224}, {win_Floor,164}, {win_Floor,132} )
> >
> > This would apply a variable height relative to the parent control,
> > up to a maximum of 132.
>
> Hmm. I dont see how this would work as stated above. To me there seems
> to be a conflict. You will notice that:
>
> {win_Floor,164}, {win_Floor,132}
>
> Both of these look exactly alike so how can it be determined that you
> mean dynamically sticky instead of a constant height?
xControls would have to see that I've already defined a height for
the control that is -5 of 100% of the parent. When it receives another
height spec for that same control, it will then have to add it to
some spec list that supplements it...
-5 of 100% of the parent up to 132.
-- the first manage spec for GMID win_Floor...
-- provides a static width ({win_Floor,164}) and variable height ({1.0,-5})
manage( GMID, win_Floor, {0,4}, {0,224}, {win_Floor,164}, {1.0,-5} )
-- this second manage spec is 75% the same as the last
-- but now provides a max height in {win_Floor, 132}
manage( GMID, win_Floor, {0,4}, {0,224}, {win_Floor,164}, {win_Floor,132} )
> > Or use a supplement...
> >
> > manage( GMID, win_Floor, {0,4}, {0,224}, {win_Floor,164}, {1.0,-5} )
> > manage_max( win_Floor, 0, 132 ) -- width, height
> >
> > This enhances the library in a logical way.
>
> I do agree with this. If I do decide to add this in it would be either
> this way or devise a completely new syntax for the creation with backwards
> compatibility.
>
> > IMO, this goes against the purpose of the xControls library, which is
> > to automagically manage sizes and positions without having to use
> > extra code.
>
> Actually I disagree with this.
Why I oughta...
> Its intended purpose is to give people a
> simple interface to do simple windows management. The fact that it can
> also handle some complex management is a bonus. It is not (and was not)
> intended to be an "end all" solution. If it beyond the scope of this
> library to handle, it is probably complicated enough to warrant hard
> coding...
Same to you and more of it.
> No, actually it doesnt. The main reason I am hedging on this is that
> at the moment, the code is short, sweet, and to the point. Its a very
> basic loop which can run very fast with a minimal of overhead and almost
> no conditional branching. Which I actually find amazing considering
> how flexible it is.
Good points. You know how us users have to push for more functionality
from our favorite libraries... :P
> Basically it gets down to adding something like this would require alot
> of conditional checks and code. While it would make your application
> smaller and easier to read, for anyone not actually using this kind of
> window they would suffer a performance hit.
I doubt it would be that drastic a hit. In fact, it might just add
an item or two to the "basic loop" you reference above. However, since
you authored the thing, I'll take your word for it... for now. ;)
-=ck
"Programming in a state of EUPHORIA."
10. Re: xControls How To
> > > What about something like this:
> > >
> > > manage( GMID, win_Floor, {0,4}, {0,224}, {win_Floor,164}, {1.0,-5} )
> > > manage( GMID, win_Floor, {0,4}, {0,224}, {win_Floor,164}, {win_Floor,132}
> > > )
> > >
> > > This would apply a variable height relative to the parent control,
> > > up to a maximum of 132.
> xControls would have to see that I've already defined a height for
> the control that is -5 of 100% of the parent. When it receives another
> height spec for that same control, it will then have to add it to
> some spec list that supplements it...
>
> -5 of 100% of the parent up to 132.
>
> -- the first manage spec for GMID win_Floor...
> -- provides a static width ({win_Floor,164}) and variable height ({1.0,-5})
> manage( GMID, win_Floor, {0,4}, {0,224}, {win_Floor,164}, {1.0,-5} )
> -- this second manage spec is 75% the same as the last
> -- but now provides a max height in {win_Floor, 132}
> manage( GMID, win_Floor, {0,4}, {0,224}, {win_Floor,164}, {win_Floor,132} )
Ahhh now I see what you meant. I read that wrong the first time, but
the same general principle applies here also. I should explain this
better...
Shortly after Geometry was released, it was suggested (by Derek?) that
it would be nice to have the ability to change settings for the controls
after they were already defined...
Original code:
manage( GMID, win_Floor, {0,4}, {0,224}, {win_Floor,164}, {1.0,-5} )
manage( GMID, win_Floor, {0,4}, {0,224}, {win_Floor,164}, {win_Floor,132} )
This was an error originally because the lib couldnt handle redefinitions.
Modified:
This was ok now. It would be redefined to the second. And actually this
is how I was able to provide a solution to your problem via the extra
little routine to your code. I cant change this to your requested
syntax without breaking existing applications that currently use this
method.
> Good points. You know how us users have to push for more functionality
> from our favorite libraries... :P
>
> > Basically it gets down to adding something like this would require alot
> > of conditional checks and code. While it would make your application
> > smaller and easier to read, for anyone not actually using this kind of
> > window they would suffer a performance hit.
>
> I doubt it would be that drastic a hit. In fact, it might just add
> an item or two to the "basic loop" you reference above. However, since
> you authored the thing, I'll take your word for it... for now. ;)
While I still do not think Geometry should support this, I *do* think
LimitSize should be looked into a bit closer. Its main purpose is to
limiting the size of main applications, but I see no reason off the top
of my head why controls cant be handled... I remember an earlier post from
you stating you tried it so I am assuming that it did not work. I will
look into this as I might be able to come up with something along those
lines.
Don Phillips - aka Graebel
National Instruments
mailto: eunexus @ yahoo.com
