Hello, > Steve, do you agree that it adds all the functionality of hooks?
It does seem to, depending on what event_map actually is. If a user could add events to the event map that werent already there, something like: Win32::GUI::RegisterEvent(0x14,"EraseBackground"); Then it would implement *some* of the functionality of hooks. The primary thing about the hooks that I thought was a good benefit was the ability to register several handlers per event. Say someone wrote a perl module that extended the RichEdit control so that all text was syntax-hilighted. For ease of use the perl module would either need to create its own RichEdit control or be passed one to work with. The module may need to handle events from the RichEdit control transparently, while still allowing the user's script to register event handlers and work with the RichEdit control normally. With hooks, this is easy. The author of the RichEdit syntax-hilight module simply Hook()s the messages that need to be captured. Since the hooks system lets you add as many event handlers per message ID as you like (the handler coderefs are simply stored in a big array and called in sequence), the user can still Hook() the same messages, or use the NEM or OEM to capture the same messages without breaking the RichEdit Syntax Hilight module functionality. Hooks are also removable. You can remove hooks by passing the coderef of the handler you want to remove to UnHook(). I'm not sure if the proposed model would let you do things like this. The system for Hooks is kinda messy and a bit of a bolt-on, but it's quite useful. The other points are good, but i've got a small issue with documentation: Having used the documentation system currently within Win32::GUI's source, i found it straightforward and simple to understand, quick to write and easilly convertable. What I'd like to see is a few improvements to the parser: 1. Support for a marker of some kind that indicates that the text should be monospaced 2. Wiki-compatible output would be great. This isn't difficult. What I mean is, a straight block of text that can be pasted right into a wiki input form. I think we *need* a wiki because docs are no good lurking in the source where users can't see them or update them. 3. Better support for documenting events, especially with the UEM coming up. 4. Bugfix and standardize the "see also xxx" parsing. Perhaps have automatic See Also parsing which makes any word that is a win32::gui method or event name a link to docs on that thing. Those would all be pretty easy to do, and I'm happy with fixing up the documentation tools if nobody else can be bothered. The ability to generate POD, HTML and TXT outputs is very handy. Glenn's other points are well made. I like the idea of checking the symbol table and resolving OEM events on startup. This would certainly make things a good deal faster, not that I really notice the slow speed of events right at the moment (and hell, I use hooks, which are incredibly slow). I mentioned Unicode support because it's been asked for a few times on the sf bug tracker. Personally I don't need it, but like I said it would be good to support this. I have noticed that in windows 2000 labels, buttons etc support Japanese characters under Win32::GUI provided that your OS language is set to Japanese (_that_ was a disorienting few hours (no pun intended :/)...). This is true of XP as well. Steve > -----Original Message----- > From: Glenn Linderman [mailto:[EMAIL PROTECTED] > Sent: 24 February 2004 02:50 > To: Aldo Calpini > Cc: Stephen Pick; Win32 GUI Hackers (E-mail); Jez White (E-mail) > Subject: Re: [perl-win32-gui-hackers] Menus and NEM > > > On approximately 2/20/2004 8:17 AM, came the following characters from > the keyboard of Aldo Calpini: > > hello people :-) > > > > On Mon, 2004-02-16 at 13:53, Stephen Pick wrote: > > > >>Hello, > >> > >>Looks like menus are indeed a little busted. You can't use both > >>event models on a menu. You can use either the NEM or the OEM, but > >>you can't selectively use NEM here and OEM there. If you add a menu > >>to a window that is using the NEM and your window uses OEM, > your menu > >>won't work. Your menu's event model must match that of the window > >>you're adding it into. > > > > > > as I said a lot of time ago, the current OEM/NEM interoperability > > implementation is going to die. there's too much broken > code in there, > > and I thought of a way to simplify things a lot (but they will be > > managed a little bit differently). > > > > the last time I wrote here, I promised a document describing the new > > architecture that I'm going to implement, but in the mean > time a damn > > stupid 120 GB external USB HD ate my development directory. > more than 1 > > GB of stuff, more than 6 years of development, sigh :-( > > > > so, the whole thing exists only in my mind now. > > > > basically, the idea is the following: there will be a > single messageloop > > for each window (including controls), which, in pseudocode, > should do > > something like this: > > > > if(event_model & BYREF) { > > if(window->eventmap(event_id)) { > > event = window->events{get_event_name(event_id)}; > > fire_event(event); > > } > > } > > if(event_model & BYNAME) { > > event_name = window->name . "_" . get_event_name(event_id); > > if(event = perl_get_cv(event_name)) { > > fire_event(event); > > } > > } > > > > the biggest implication is that the OEM (BYNAME event model) will > > probably result a little bit slower: that's because each > message to each > > control will trigger a perl_get_cv call (which is orders of > magnitude > > slower than a C instruction). on the other hand, every > control will have > > the whole range of events (eg. MouseMove, MouseClick, etc.) > enabled by > > default. > > > > event_model in the code above is a global variable in C > which will be > > controlled by a method (Win32::GUI::SetEventModel or something like > > that) or by a directive in use (eg. use Win32::GUI EventModel => > > 'BYREF'). > > This does sound like it would unify the event models, and add all the > functionality Steve has added via the hooks. Steve, do you > agree that > it adds all the functionality of hooks? I've not yet played > with them > to be 100% sure. > > One could, however, provide a very simple migration path from > slow OEM > performance to fast OEM performance, with one restriction: > If the OEM > functions are required to exist at the time a window is > created, then at > window creation time, the namespace could be searched for the > names of > event functions, and they could be collected into the same data > structures that are used by NEM. > > This would eliminate a dynamic performance penalty of OEM, at > the cost > of a creation time performance penalty for OEM. It would > eliminate any > need to record, for each window, whether it uses OEM or NEM. > > Actually, users could almost perform the OEM->NEM conversion just by > adding the appropriate event names pointing at their old OEM > functions... Except, if the calling convention for the OEM > functions and > NEM functions vary, then they couldn't be used > interchangably. And that > seems to be part of the design for compatibility... but maybe that is > solvable somehow? With the "automatic" migration, a simple wrapper > function could be interposed between the NEM calling function > parameters, and the OEM calling function parameters, which > would still > likely be faster than doing all the perl_get_cv's at > run-time? This is > discussed more under "Re: parameter passing" below... > > > I'm a little (oh, well, a little is not enough :-) behind with the > > situation on CVS, but I'm ready to implement this > architectural change. > > > > should we branch the CVS repository (or create a new module, which > > sounds better to me) or is the current status quiet enough to begin > > working on this for the next release? > > Well, the CVS repository is already branched, bugfix vs development. > However, it would be a shame to lose all the bugfix work, if you are > ready to start implementing afresh. > > I would suggest that a cooperative approach would be for you > to review > the major code changes, and either accept them, or discuss > them in this > forum, until some consensus can be reached. > > We should do a release of what we have so far, subject to discussions > started by the last paragraph, before starting another major > initiative. > And if you wouldn't mind starting from the current bug-fix > branch code > (after the release), then the next release point could be merged back > into the main branch, and you could do your upward-compatible > development there. Bug fixing could continue on the bug fix > branch, and > you could pick up the bug fixes from time to time in the main > branch, so > there wouldn't be a major synchronization issue later. > > It sounds to me like the hooks will become somewhat redundant > as a way > of capturing messages, but I doubt that they are seriously > difficult to > support in deprecated mode, even if they are redundant. > > It is important to me that you retain the ability to set and fetch > pointers to the functions that get invoked for messages, which Steve > only recently added to the NEM. > > > I'll comment on a few of the other threads of discussion, but won't > reproduce them here. > > Re: context: yes, it would be nice to be able to invoke GUI functions > from any thread, and even have "fake-forked" programs be able to have > independent windows, if that is straightforward. > > Re: DESTROY: of course it would be nice, but except for > really dynamic > programs, not all that necessary. In other words, not the > highest priority. > > Re: VB-likeness. Not important to me in the least. Useful > and usable > are much more important. VB isn't really very object > oriented; we can > be much more so in Perl. > > Re: PEM. No comment, until we hear more. > > Re: Refactoring code: Certainly improvements could and should > be made to > the structure of the code. > > Re: Unicode, I think you understand the main difficulty, UCS2-LE (I'm > not sure what the -LE means, though) vs UTF-8. But there should be > samples of such conversions inside the Perl core (Windows port). > > Re: parameter passing: Passing the object as a first > parameter to each > of the event handling functions is an excellant idea. As > well as all of > the numbers fromthe event message itself. We need to allow a > Win32::GUI > program all the power of the C program. There is a > compatibility issue > here. Neither the OEM nor NEM models pass such a parameter > at present. > So we can either figure out ways of passing the parameter > that isn't > "clean", but is compatible, and new or modified functions can > access the > appropriate object, or we need to define UEM (unified event > model) which > has the object, and can provide compatible interfaces for > existing OEM > and NEM functions. I think the latter is relatively straightforword: > the UEM provides a new interface for UEM-aware functions, and > provides > the old interfaces for NEM-aware functions (and a > compatibility layer to > call that code, and convert the parameters), and converts > pre-existing > OEM functions to NEM functions (with the same, or perhaps with a > slightly different compatibility layer). The only thing > > Re: performance: we won't want to see a C/Perl transition on > EVERY mouse > move, for performance reasons. Perhaps we need to define a clean way > for defining UEM functions in either Perl, or C? And if the > function is > defined in C, there needs to be a way to call it from C > without hopping > through Perl. But there also needs to be a way of calling it > from Perl, > in case it is overridden by Perl code, that wants to augment the > previous function by doing something, calling the previous function, > doing some more, and then returning. This could be a bit > tricky. Maybe > it can be defined away somehow, but the ability to override > and augment > the existing functions is important for me. But I'm not sure > it is all > that important for the functions which need speed. So if > there is not a > universal way to do this, perhaps some restrictions on what functions > may and may not be defined using C is OK. > > Re: documentation: What this project doesn't need, is any more > undocumented capabilities. The greatest feature in the world > is totally > useless if no one can figure it out. And there are lots of great > features in Win32::GUI that very few people could figure out. Having > all the documentation on sourceforge would help. And maybe > wiki's are > the next greatest thing, but the use of too many different types of > technology can prevent a steep learning curve for potential > contributors. Erick's existing Win32::GUI Documentation > project suffers > from the inability of contributers to figure out how to > contribute, even > with help from Erick. No doubt the system works for Erick, but it's > visual cues aren't consistent with the selected operations I > attempted, > so it continually convinced me that it wasn't doing what I > asked it to > do, before I got far enough to actually do anything. Calling > this new > wiki the "Win32::GUI Documentation Project" is somewhat confusing in > light of Erick's existing project. I think it should be called > something else. I'm also not sure that it should be a wiki, > vs simply a > collection of CVS controlled POD files, but feel free to > convince me or > ignore me, but I would like some insight as to what made you > choose to > create a wiki. > > -- > Glenn -- http://nevcal.com/ > =========================== > The best part about procrastination is that you are never bored, > because you have all kinds of things that you should be doing. > >
