1. Win32lib additions [3]
- Posted by euman at bellsouth.net May 28, 2003
- 421 views
{{{ Hello again Derek,
Could you change this in Win32lib?
make [window_handle] a global sequence
controls global sequence window_handle hwnd of controls
sequence window_handle_type, Type of handle window_destroyed, true if destroyed etc...etc
Euman
2. Re: Win32lib additions [3]
- Posted by Derek Parnell <ddparnell at bigpond.com> May 29, 2003
- 411 views
----- Original Message ----- From: <euman at bellsouth.net> To: "EUforum" <EUforum at topica.com> Subject: Win32lib additions [3] Hello again Derek, Could you change this in Win32lib? make [window_handle] a global sequence -- controls global sequence window_handle -- hwnd of controls sequence window_handle_type, -- Type of handle window_destroyed, -- true if destroyed --etc...etc ------------ Derek replies.... Absolutely NOT! This is against good programming practices as it opens up the library to changes that it cannot control. If you need access to the values in this fields, you can ALREADY do that by calling the getControlInfo() routine. lValues = getControlInfo(myWin, {CONTROLINFO_handle, CONTROLINFO_handle_type, CONTROLINFO_destroyed }) will return a sequence containing the three requested values. However, if you just want the handle info you can use the (undocumented) getHWND(id) function. Or the function getHandles() to get every handle that win32lib has. I will not expose anymore variables as global - there are too many already exposed. ------- Derek.
3. Re: Win32lib additions [3]
- Posted by euman at bellsouth.net May 29, 2003
- 391 views
{{{ I dont understand Derek,
I'll just continue to make the change to Win32lib on my own and for those who want to gain a bit of speed set window_handle as global so you can use the [internal] Win32lib sequence like this:
ListLV = create(ListView, "",hWnd, x1, y1,x2, y2, flags) hListLV window_handle[ListLV] later when messages are needed to be sent VOID = w32Func( xSendMessage, {hListLV, etc..etc
instead of having to process hundreds of lines in Win32lib trying to send a simple message.
Im not saying you arent right Derek about good programming practice but when speed counts and it does, why not use something Win32lib [internally] uses on a regular basis. Are you saying we arent smart enough to use this sequence? never mind, just on a soapbox...
Euman
--- Original Message From: "Derek Parnell" <ddparnell at bigpond.com>
From: <euman at bellsouth.net>
To: "EUforum" <EUforum at topica.com>
Sent: Wednesday, May 28, 2003 10:05 PM
Subject: Win32lib additions [3]
Could you change this in Win32lib?
make [window_handle] a global sequence
sequence
window_handle_type,
---------
lValues = getControlInfo(myWin,
{CONTROLINFO_handle,
CONTROLINFO_handle_type,
CONTROLINFO_destroyed
})
will return a sequence containing the three requested values.
However, if you just want the handle info you can use the (undocumented)
getHWND(id) function. Or the function getHandles() to get every handle that
win32lib has.
I will not expose anymore variables as global - there are too many already
exposed.
----
4. Re: Win32lib additions [3]
- Posted by Derek Parnell <ddparnell at bigpond.com> May 29, 2003
- 408 views
>----- Original Message ----- >From: <euman at bellsouth.net> >To: "EUforum" <EUforum at topica.com> >Subject: Re: Win32lib additions [3] > > >I dont understand Derek, You're not the first to say that they don't understand me >I'll just continue to make the change to Win32lib on my own and for >those who want to gain a bit of speed set window_handle as global That's your call and that's okay by me. Win32lib has never be designed for those people who need as much speed as possible. If you need a faster way to code windows programs then don't use win32lib, or adapt a version for your own purposes. Win32lib is designed to be quick at CREATING and MAINTAINING Windows programs. Execution speed is not its highest priority. Its is designed to make Windows programming easier by doing a lot of the housekeeping. In order to do that, it generalizes a LOT of code - and that does not make for optimal speed. I know you know this stuff already but I'll say it again anyway, for the benefit of our listening audience Generally speaking, there is always a trade-off between execution speed and functionality. There is lots of functionality inbuilt into this library at the cost of execution speed. And that seems to suit a lot of people, by the way. >so you can use the [internal] Win32lib sequence like this: > >ListLV = create(ListView, "",hWnd, x1, y1,x2, y2, flags) >hListLV = window_handle[ListLV] >--later when messages are needed to be sent >VOID = w32Func( xSendMessage, {hListLV, etc..etc > >instead of having to process hundreds of lines in Win32lib trying to send >a simple message. "hundreds"? Are you joking? How about this instead... ListLV = create(ListView, "",hWnd, x1, y1,x2, y2, flags) hListLV = getHWND(ListLV) --later when messages are needed to be sent VOID = w32Func( xSendMessage, {hListLV, etc..etc If you look at the getHWND function it turns out to be "return window_handle[ListLV]", hardly a lot of overhead there. In fact, the w32Func call has *way* more overhead and I guess you'll be calling that heaps more times than the getHWND call. If you really are running on a slow machine, you would be better to code it in 'raw' Euphoria or even Masm32 instead. >Im not saying you arent right Derek about good programming practice but >when speed counts and it does, why not use something Win32lib [internally] >uses on a regular basis. Whether it takes 10 milliseconds or 100 milliseconds to get a control's handle is not going to worry most people. Sure speed counts, but getting speed costs. Count the cost, and make a trade-off that suits your purposes. Many studies have shown that the best way to speed up an application is to improve the algorithms, rather than optimise the code. You can spend far more time in creating and maintaining optimised code than the time it saves during execution. >Are you saying we arent smart enough to use this sequence? Of course not! I'm trying to make life easier for us all. For example, if window_handle is made global, an accidental bug can write stuff into that variable and cause problems that could be very hard to track down. Another issue is that if I decide to change the internal use of this field, or do away with it altogether, then your program and any others that DEPEND on window_handle will break. This is a real concern. For example, there are a whole heap of internal fields associated with each instantiated control. Currently these are each in their own sequence. Someday in the future I might change this in to a different structure due to performance reasons (or some other valid reason). But if I made this or similar internal fields global, I'd always be worried about breaking people's programs. That is why I publish global routines. Their interface to user's code does not change. So if your code uses getHWND(id) and I do change the internal structures, this routine will still work as advertised. >never mind, just on a soapbox... Soapboxes are good - so long as one can hear their audience from up there.
5. Re: Win32lib additions [3]
- Posted by gertie at visionsix.com May 29, 2003
- 407 views
On 29 May 2003, at 23:23, Derek Parnell wrote: <snip> > ListLV = create(ListView, "",hWnd, x1, y1,x2, y2, flags) > hListLV = getHWND(ListLV) > --later when messages are needed to be sent > VOID = w32Func( xSendMessage, {hListLV, etc..etc > > If you look at the getHWND function it turns out to be "return > window_handle[ListLV]", hardly a lot of overhead there. /me shivers in horror at the unknown. That is so far from puts(). Any chance the function names can be friendly words we all know and love? Kat
6. Re: Win32lib additions [3]
- Posted by Derek Parnell <ddparnell at bigpond.com> May 29, 2003
- 385 views
----- Original Message ----- From: <gertie at visionsix.com> To: "EUforum" <EUforum at topica.com> Subject: Re: Win32lib additions [3] > > > On 29 May 2003, at 23:23, Derek Parnell wrote: > > <snip> > > > ListLV = create(ListView, "",hWnd, x1, y1,x2, y2, flags) > > hListLV = getHWND(ListLV) > > --later when messages are needed to be sent > > VOID = w32Func( xSendMessage, {hListLV, etc..etc > > > > If you look at the getHWND function it turns out to be "return > > window_handle[ListLV]", hardly a lot of overhead there. > > /me shivers in horror at the unknown. That is so far from puts(). Any chance > the function names can be friendly words we all know and love? > The abbreviation "HWND" is well known to Windows coders, thanks to Mircosoft. I suppose I could have called the routine 'get_the_handle_of_the_control()'. And of course, RDS should rename the cryptic 'puts()' to 'output_the_string()' -- Derek
7. Re: Win32lib additions [3]
- Posted by "C. K. Lester" <cklester at yahoo.com> May 29, 2003
- 409 views
> > /me shivers in horror at the unknown. That is so far from puts(). Any > > chance > > the function names can be friendly words we all know and love? > > The abbreviation "HWND" is well known to Windows coders, thanks to > Mircosoft. > > I suppose I could have called the routine 'get_the_handle_of_the_control()'. > And of course, RDS should rename the cryptic 'puts()' to > 'output_the_string()' Derek, I'm struck with awe at your comments. You know full well that it would be "output_the_sequence()," you defiler of truth! (Hey, keep up the otherwise good work.) :P
8. Re: Win32lib additions [3]
- Posted by Derek Parnell <ddparnell at bigpond.com> May 29, 2003
- 394 views
----- Original Message ----- From: "C. K. Lester" <cklester at yahoo.com> To: "EUforum" <EUforum at topica.com> Subject: Re: Win32lib additions [3] > > > > > /me shivers in horror at the unknown. That is so far from puts(). Any > > > chance > > > the function names can be friendly words we all know and love? > > > > The abbreviation "HWND" is well known to Windows coders, thanks to > > Mircosoft. > > > > I suppose I could have called the routine > 'get_the_handle_of_the_control()'. > > And of course, RDS should rename the cryptic 'puts()' to > > 'output_the_string()' > > Derek, I'm struck with awe at your comments. You know full well that it > would be "output_the_sequence()," you defiler of truth! (Hey, keep up the > otherwise good work.) :P > Does this ring a bell? ... "sequence found inside character string" And thanks for the support. -- Derek
9. Re: Win32lib additions [3]
- Posted by "C. K. Lester" <cklester at yahoo.com> May 29, 2003
- 378 views
> > > > /me shivers in horror at the unknown. That is so far from puts(). Any > > > > chance > > > > the function names can be friendly words we all know and love? > > > > > > The abbreviation "HWND" is well known to Windows coders, thanks to > > > Mircosoft. > > > > > > I suppose I could have called the routine > > 'get_the_handle_of_the_control()'. > > > And of course, RDS should rename the cryptic 'puts()' to > > > 'output_the_string()' > > > > Derek, I'm struck with awe at your comments. You know full well that it > > would be "output_the_sequence()," you defiler of truth! (Hey, keep up the > > otherwise good work.) :P > > Does this ring a bell? ... > "sequence found inside character string" Touche... However, the following is much louder: puts Syntax: puts(fn, x) Description: Output, to file or device fn, a single byte (atom) or sequence of bytes. The low order 8-bits of each value is actually sent out. If fn is the screen you will see text characters displayed. Comments: When you output a sequence of bytes it must not have any (sub)sequences within it. It must be a sequence of atoms only. (Typically a string of ASCII codes). Avoid outputting 0's to the screen or to standard output. Your output may get truncated. Example 1: puts(SCREEN, "Enter your first name: ") Example 2: puts(output, 'A') -- the single byte 65 will be sent to output See Also: printf, gets, open However, the docs also say this: puts - output a string sequence to a file or device A string sequence?! Rob!! That must be a typo. > And thanks for the support. Thank you for giving me something to support. -ck
10. Re: Win32lib additions [3]
- Posted by jbrown1050 at hotpop.com May 29, 2003
- 400 views
On Thu, May 29, 2003 at 08:30:27AM -0400, euman at bellsouth.net wrote: > > I dont understand Derek, Its not that hard to understand. > > I'll just continue to make the change to Win32lib on my own and for > those who want to gain a bit of speed set window_handle as global > so you can use the [internal] Win32lib sequence like this: > > ListLV = create(ListView, "",hWnd, x1, y1,x2, y2, flags) > hListLV = window_handle[ListLV] > --later when messages are needed to be sent > VOID = w32Func( xSendMessage, {hListLV, etc..etc > > instead of having to process hundreds of lines in Win32lib trying to send > a simple message. > Or .... hListLV = getHandle(ListLV) -- I think Derek called this getHWND() That would basicly do the same thing. > Im not saying you arent right Derek about good programming practice but > when speed counts and it does, why not use something Win32lib [internally] > uses on a regular basis. Are you saying we arent smart enough to use this > sequence? never mind, just on a soapbox... Basicly, what if a later revision of win32lib were to change, and for some reason window_handle[] had to be removed? Every program that used it directly would break! However, if the access to window_handle[] was in getHandle(), then all that would have to be done is to rewrite getHandle(), and all programs would again work flawlessly. That also, I believe, is the reason Derek dislikes onClick[] and friends so much ... > > Euman > jbrown > ----- Original Message ----- > From: "Derek Parnell" <ddparnell at bigpond.com> > > > ----- Original Message ----- > > From: <euman at bellsouth.net> > > To: "EUforum" <EUforum at topica.com> > > Sent: Wednesday, May 28, 2003 10:05 PM > > Subject: Win32lib additions [3] > > > Hello again Derek, > > > > Could you change this in Win32lib? > > > > make [window_handle] a global sequence > > > > -- controls > > global sequence > > window_handle -- hwnd of controls > > > > sequence > > window_handle_type, -- Type of handle > > window_destroyed, -- true if destroyed > > --etc...etc > > > > ------------ > > Derek replies.... > > Absolutely NOT! This is against good programming practices as it opens up > > the library to changes that it cannot control. If you need access to the > > values in this fields, you can ALREADY do that by calling the > > getControlInfo() routine. > > > > lValues = getControlInfo(myWin, > > {CONTROLINFO_handle, > > CONTROLINFO_handle_type, > > CONTROLINFO_destroyed > > }) > > will return a sequence containing the three requested values. > > > > However, if you just want the handle info you can use the (undocumented) > > getHWND(id) function. Or the function getHandles() to get every handle that > > win32lib has. > > > > I will not expose anymore variables as global - there are too many already > > exposed. > > > > ------- > > Derek. > > > > TOPICA - Start your own email discussion group. FREE! > -- /"\ ASCII ribbon | http://www.geocities.com/jbrown1050/ \ / campain against | Linux User:190064 X HTML in e-mail and | Linux Machine:84163 /*\ news, and unneeded MIME |
11. Re: Win32lib additions [3]
- Posted by euman at bellsouth.net May 30, 2003
- 384 views
JBrown, Do you really think I didn't understand? Written about as much or more API than Win32lib has in it.. Euman
12. Re: Win32lib additions [3]
- Posted by jbrown105 at speedymail.org May 30, 2003
- 390 views
On Fri, May 30, 2003 at 08:03:23AM -0400, euman at bellsouth.net wrote: > > > JBrown, > > Do you really think I didn't understand? Thats what I believed you had said. If I misunderstood, I apologize for answering such a redundant question. ;p > > Written about as much or more API than Win32lib has in it.. Not that the reluctance to expose global variables in win32lib is directly related to WinAPI, of course. (For example, its a bad idea to expose globally a sequence that is used for, say, simulated OOP, for the exact same reason.) The only possible reason I can see for the preference to expose global variables in win32lib over the use of functions is for speed purposes. Also, using such variables in win32lib makes it much harder to make Llama compatible with it. (Llama will never support onClick[], for example, tho it does support setHandler().) (Not that Llama is a very good example, it has a ton of exposed variables, tho I'm working on that.) > > Euman > jbrown -- /"\ ASCII ribbon | http://www.geocities.com/jbrown1050/ \ / campain against | Linux User:190064 X HTML in e-mail and | Linux Machine:84163 /*\ news, and unneeded MIME |