Re: w32feature()
- Posted by CChris <christian.cuvier at agriculture.gouv??r> Jun 05, 2008
- 726 views
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