1. w32feature()
I don't expect to put this in win32lib v0.70.4a, but perhaps in 70..
Some behaviours of the library are not quite right, but they have been that way
for a long time and code is using or working around the behaviour.
I'm contemplting the addition of a w32feature(name) or w32feature(name,state=on)
proedure that would act a little like a with/without directive in this egard.
Here are the first wo features I thought about:
1/It had been requested that getRect'Screen) return th usable screen area (ie
withut the taskbar, appbars and stuff) raher than the whole screen area. But this
has disturbed some code (search EuForum for win32lib docked). A call to
w32feature("screen_actual_rect") would activate the current behaviour, default
being the older one.
2/ Controls on TabItems currently need to adjust their y position if they don't
want to overlap the tabs, which is something I wouldn't usually do. It would be
possile to have proper client adjustment in TabControls, but it is not there and
much code is working around it. w32feature("adjust_tabctrl_rect") would enable
the newer, nicer behaviour, default being the current.
Any thoughts?
CChris
2. Re: w32feature()
CChris wrote:
>
>
> I don't expect to put this in win32lib v0.70.4a, but perhaps in 70..
>
> Some behaviours of the library are not quite right, but they have been that
> way for a long time and code is using or working around the behaviour.
>
> I'm contemplting the addition of a w32feature(name) or
> w32feature(name,state=on)
> proedure that would act a little like a with/without directive in this egard.
>
> Here are the first wo features I thought about:
>
> 1/It had been requested that getRect'Screen) return th usable screen area (ie
> withut the taskbar, appbars and stuff) raher than the whole screen area. But
> this has disturbed some code (search EuForum for win32lib docked). A call to
> w32feature("screen_actual_rect") would activate the current behaviour, default
> being the older one.
>
> 2/ ...
> Any thoughts?
>
> CChris
I think it should only be getClientRect(Screen) that returns the usable area.
getRect(Screen) should return the full screen as before.
Compare getClientRect(<Window>) and getRect(<Window>) which return the
areas inside and outside the borders.
Arthur Crump (UK)
3. Re: w32feature()
Arthur Crump wrote:
>
> CChris wrote:
> >
> >
> > I don't expect to put this in win32lib v0.70.4a, but perhaps in 70..
> >
> > Some behaviours of the library are not quite right, but they have been that
> > way for a long time and code is using or working around the behaviour.
> >
> > I'm contemplting the addition of a w32feature(name) or
> > w32feature(name,state=on)
> > proedure that would act a little like a with/without directive in this
> > egard.
> >
> > Here are the first wo features I thought about:
> >
> > 1/It had been requested that getRect'Screen) return th usable screen area
> > (ie
> > withut the taskbar, appbars and stuff) raher than the whole screen area. But
> > this has disturbed some code (search EuForum for win32lib docked). A call to
> > w32feature("screen_actual_rect") would activate the current behaviour,
> > default
> > being the older one.
> >
> > 2/ ...
> > Any thoughts?
> >
> > CChris
>
> I think it should only be getClientRect(Screen) that returns the usable area.
> getRect(Screen) should return the full screen as before.
> Compare getClientRect(<Window>) and getRect(<Window>) which return the
> areas inside and outside the borders.
>
> Arthur Crump (UK)
Right, and this also applies to tab control as well.
CChris
4. Re: w32feature()
- Posted by gshingles <gshingles at gmail.co?>
Jun 04, 2008
-
Last edited Jun 05, 2008
CChris wrote:
Hi Chris, thanks for your work (and the work of everyone else who has worked on
it) on win32lib. It is still my favourite 'toolkit' since it minimises compiled
executable size and lowers distribution hassles, being native win32 based.
> I don't expect to put this in win32lib v0.70.4a, but perhaps in 70..
>
> Some behaviours of the library are not quite right, but they have been that
> way for a long time and code is using or working around the behaviour.
>
> I'm contemplting the addition of a w32feature(name) or
> w32feature(name,state=on)
> proedure that would act a little like a with/without directive in this egard.
>.....
> and much code is working around it. w32feature("adjust_tabctrl_rect") would
> enable the newer, nicer behaviour, default being the current.
>
> Any thoughts?
I like the idea (if maintainers are comfortable with the increased complexity).
I'd like to see a w32feature("long_rects") because of for example getRect
returning a 'left, top, right, bottom' and setRect taking a 'left, top, width,
height'. I'm sure there are more examples.
This makes code look messy with rect[4] - rect[2], etc all over the place and
increases the brain strain of using these functions.
So if these kinds of functions could take a single rect sequence where a rect is
'left,top,right,bottom,width,height' and all functions consistently used this,
then I would be extremely happy.
Gary
5. Re: w32feature()
- Posted by ken mortenson <kenneth_john at ya?oo.?om>
Jun 04, 2008
-
Last edited Jun 05, 2008
gshingles wrote:
> So if these kinds of functions could take a single rect sequence where a rect
> is 'left,top,right,bottom,width,height' and all functions consistently used
> this, then I would be extremely happy.
Isn't the windows standard something like (left, top, width, height) with
right and bottom being redundant?
"Science is the belief in the ignorance of experts." - Richard Feynman
6. Re: w32feature()
ken mortenson wrote:
>
> gshingles wrote:
>
> > So if these kinds of functions could take a single rect sequence where a
> > rect
> > is 'left,top,right,bottom,width,height' and all functions consistently used
> > this, then I would be extremely happy.
>
> Isn't the windows standard something like (left, top, width, height) with
> right and bottom being redundant?
That may be, but Microsoft also promotes OO languages where you can call methods
to get a width, or a height, or whatever you want. I'm just suggesting putting
most of the salient information in a small sequence to pass around. I don't think
it would add that much overhead compared with win32lib itself.
Gary
7. Re: w32feature()
A man with one watch knows the exact time. A man with two watches isn't
quite so sure!
gshingles wrote:
>
> ken mortenson wrote:
> > Isn't the windows standard something like (left, top, width, height) with
> > right and bottom being redundant?
>
> That may be, but Microsoft also promotes OO languages where you can call
> methods
> to get a width, or a height, or whatever you want. I'm just suggesting
> putting
> most of the salient information in a small sequence to pass around. I don't
> think it would add that much overhead compared with win32lib itself.
I understand that a structure that contains redundant information can be
useful. You may not want to have to derive something from something else.
The danger is that when you update you must always remember to update the
redundant information along with the information you are focussed on
updating. Otherwise, this leads to errors (like the man with two watches.)
A rectangle is defined by exactly one point which is it's dimension
(width, height) It's position is defined by exactly one point (left, top.)
In database design this principle of avoiding redundancy is normalization.
This is something I've always done long before I'd ever heard of it, which
probably explains why I'm such a stinker about this.
Please Gary, know that I understand what you are saying and my thoughts are
just my opinion. I hope I've explained clearly why I hold this opinion.
8. Re: w32feature()
ken mortenson wrote:
> In database design this principle of avoiding redundancy is normalization.
>
> This is something I've always done long before I'd ever heard of it, which
> probably explains why I'm such a stinker about this.
>
> Please Gary, know that I understand what you are saying and my thoughts are
> just my opinion. I hope I've explained clearly why I hold this opinion.
Absolutely. There is always a spectrum of opinions about anything 
My initial post is more symptomatic of win32lib's state in general, it is a
behemoth, totally mind-twisting internal code, there seems to be no overall
structure to its API, but I love it, it seems to run very efficiently and works
as you expect 99% of the time.
PS I know of one Oracle developer who told me his team routinely duplicates
entire records in the key name, the theory being redundancy is a Good Thing where
resources allow it. Natural biological systems seem to agree.
I get your point but, in general, do we want to put the complextity in the API
or on to the programmer? win32lib seems to favour the former, but doesn't, but
does, in a way...
Gary
9. Re: w32feature()
gshingles wrote:
>
> CChris wrote:
>
> Hi Chris, thanks for your work (and the work of everyone else who has worked
> on it) on win32lib. It is still my favourite 'toolkit' since it minimises
> compiled
> executable size and lowers distribution hassles, being native win32 based.
>
> > I don't expect to put this in win32lib v0.70.4a, but perhaps in 70..
> >
> > Some behaviours of the library are not quite right, but they have been that
> > way for a long time and code is using or working around the behaviour.
> >
> > I'm contemplting the addition of a w32feature(name) or
> > w32feature(name,state=on)
> > proedure that would act a little like a with/without directive in this
> > egard.
> >.....
> > and much code is working around it. w32feature("adjust_tabctrl_rect") would
> > enable the newer, nicer behaviour, default being the current.
> >
> > Any thoughts?
>
> I like the idea (if maintainers are comfortable with the increased
> complexity).
> I'd like to see a w32feature("long_rects") because of for example getRect
> returning
> a 'left, top, right, bottom' and setRect taking a 'left, top, width, height'.
> I'm sure there are more examples.
>
> This makes code look messy with rect[4] - rect[2], etc all over the place and
> increases the brain strain of using these functions.
>
> So if these kinds of functions could take a single rect sequence where a rect
> is 'left,top,right,bottom,width,height' and all functions consistently used
> this, then I would be extremely happy.
>
> Gary
You know, the issue is that win32lib has a heavy code base relying on it.
Changing anything will break something, no matter what.
The latest example is registerControl(). This was undocumented on 60.6,
precisely becaue it was liable to change, and I did need to change it. Now it is
documented, and is not likely to change, but it broke a couple things within
xConrols. Even after 70.4a is released, xControls and other libraries using
custom control will need minor editing to play along as they used to. So far, the
only issue I have found is replacing a couple "return WINDOW" by "return Window".
How s this related? Not directly, for sure. But it introduces to the problm of
evolving a widely used tooll.
The idea is that w32feature() should make it possible to choose between an
historical behaviour (default) and a newer, slightly modified one. The 6 corner
rectangle you were hinting at could be another w32feature() selectable
behaviours: historical, long recxts everywhere, shot rects everywhere.
For the library maintainers, this is hardly a problem. The issue I see is when
someone will try merging some piece of code with one option and another one ith
another option. If I could make w32feature() to push and pop its state on
entering a new include file, like for the trace or profile flags, that would be
nice. But this is not automagic.
So... as I said, I'm just floating the idea, in order to get advance feedback
and improve on it. It won't be there before 70.5, if it ever does.
CChris
10. Re: w32feature()
ken mortenson wrote:
>
> gshingles wrote:
>
> > So if these kinds of functions could take a single rect sequence where a
> > rect
> > is 'left,top,right,bottom,width,height' and all functions consistently used
> > this, then I would be extremely happy.
>
> Isn't the windows standard something like (left, top, width, height) with
> right and bottom being redundant?
>
> "Science is the belief in the ignorance of experts." - Richard Feynman
Nope, the Win32 API uses coordinates only, and win32lib tries beingmore
practical by also returning dimensions. Problem is, this is not done
consistently, for reasons which may have been apparent at a time way before I
ever knew about Euphoria.
CChris
11. Re: w32feature()
CChris wrote:
> For the library maintainers, this is hardly a problem. The issue I see is when
> someone will try merging some piece of code with one option and another one
> ith another option. If I could make w32feature() to push and pop its state on
> entering a new include file, like for the trace or profile flags, that would
> be nice. But this is not automagic.
Yuck. I see what you mean. That's getting a bit out there.
> So... as I said, I'm just floating the idea, in order to get advance feedback
> and improve on it. It won't be there before 70.5, if it ever does.
I think as long as the majority of people are using an MS operating system and
Microsoft continues to support the win32 api then the effort of continued
development is worth it.
Other GUI libraries are available but I think there will always be a place for
the native win32 stuff for reasons of compactness, speed and ease of
distribution.
In other words, keep on trucking :) I predict great debates about win32lib in
the future, after the dust of language features has settled a bit.
Gary
12. Re: w32feature()
CChris wrote:
>
>
> I don't expect to put this in win32lib v0.70.4a, but perhaps in 70..
...
> I'm contemplting the addition of a w32feature(name) or
> w32feature(name,state=on)
> proedure that would act a little like a with/without directive in this egard.
...
> Any thoughts?
>
> CChris
I would like to suggest w32feature(<version>,state=on)
to include ALL the features of the specified version.
Arthur Crump
13. Re: w32feature()
- Posted by CChris <christian.cuvier at agriculture.gou?.?r>
Jun 06, 2008
-
Last edited Jun 07, 2008
Arthur Crump wrote:
>
> CChris wrote:
> >
> >
> > I don't expect to put this in win32lib v0.70.4a, but perhaps in 70..
> ...
> > I'm contemplting the addition of a w32feature(name) or
> > w32feature(name,state=on)
> > proedure that would act a little like a with/without directive in this
> > egard.
> ...
> > Any thoughts?
> >
> > CChris
>
> I would like to suggest w32feature(<version>,state=on)
> to include ALL the features of the specified version.
>
> Arthur Crump
Interesting, but not quite practical.
If "feture" includes any new stuff, then you have a simpler way, which is to
keep the older version. If the scope is restricted to changes, welll that becomes
more feasible.
I don't think I'd go through the change log to rebuild all layers of change,
including from a recent date. Were you implying this?
CChris
14. Re: w32feature()
CChris wrote:
...
> > > I'm contemplting the addition of a w32feature(name) or
> > > w32feature(name,state=on)
> > > procedure that would act a little like a with/without directive in this
> > > regard.
...
> > > CChris
...
> > Arthur Crump wrote:
> > I would like to suggest w32feature(<version>,state=on)
> > to include ALL the features of the specified version.
...
> Interesting, but not quite practical.
> If "feature" includes any new stuff, then you have a simpler way, which is to
> keep the older version. If the scope is restricted to changes, welll that
> becomes
> more feasible.
> I don't think I'd go through the change log to rebuild all layers of change,
> including from a recent date. Were you implying this?
>
> CChris
I had not thought about the implications of backdating it to early versions.
I agree: that would not be feasible. Even if new additions could be flagged
as belonging to a specific version, the earlier additions could make nonsense of
it.
Probably the earliest version that could be set may be the version with
feature().
This could lead some programmers to the requirement to use two or more versions,
depending upon the application.
The thread 'EuDir and EuInc' could suggest how to do this.
Arthur Crump
I have been programming for nearly fifty years but only for three in Euphoria.
I have not contributed to the archive so my input does not have much value.
