Re: w32feature()

new topic     » goto parent     » topic index » view thread      » older message » newer message

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

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu