From: Glenn L. <pe...@ne...> - 2003-11-28 20:31:18
Attachments:
patch.txt
|
Hi Laurent, Due to my hard drive being in the process of failing, I thought I'd better get this patch isolated and delivered to you, so that it won't get lost. Plus maybe Glenn Munroe might be able to use it, and others. Here is a description of all the changes I've made, which you can use as needed as comments in the change log(s). The patch.txt was generated by diff -r -c against the released version of 0.0.665 sources, not including any patches you've already applied to the CVS bugfix branch. I hope that works for you... if it is hard, let me know what I should provide instead. I included a patch the change the version from 0.0.665 to 0.0.680 ... I really don't care what the final number is, but probably it shouldn't be 0.0.665 ... we should use a different number, changing it for each patch applied, perhaps. And maybe Aldo could bump the first or second number in the main branch, for anything he does there? There is a fix for an uninitialized variable reference, maybe you've already picked that up, this is in the tooltip handling code. There is a fix to add additional Windows constants for use with TrackPopupMenu, these are TPM_* constants. There is a fix to add many additional possible accelerator keys. I tried to include all the ones that sounded like they were not guaranteed to vary on other keyboards, and tried to consolidate documentation for all keys I could find documentation for into the code, even if some of them are commented out, so if someone needs one I commented out, it should be easy to add it in. There is a fix to NotifyIcon destruction, to avoid warnings when the destruction by shutting down the process might conflict with destruction by hand. Not clear which one happens first, all the time. There are fixes to the bugs that prevented accelerator keys from working. I left in some commented out code that shows how to trigger the MS Visual Studio debugger in a somewhat clean way, in case that code might be useful to someone, either where it is, or to paste it somewhere else. In GUI_MessageLoops, most of the changes are to move calls to the DefWindowProc to a common spot, so that when you add debugging code, you can monitor all the calls to DefWindowProc from one spot in the code, rather than scattering the debugging code into over a dozen other places. This also unifies the "STRONGDEBUG" code that already preceeding most, but not all, of the former calls to DefWindowProc. This is in the nature of code cleanup, and making things easier to debug, but don't actually change the functionality of Win32::GUI. -- Glenn -- http://nevcal.com/ =========================== Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates And here is why it is ridiculous: The division that includes Windows posted an operating profit of $2.26 billion on revenue of $2.81 billion. --from Reuters via http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html So that's profit of over 400% of investment... with a bit more investment in Windows technology, particularly in the area of reliability, the profit percentage might go down, but so might the bugs and security problems? Seems like it would be a reasonable tradeoff. WalMart earnings are 3.4% of investment. |
From: Laurent R. <ro...@cl...> - 2003-11-29 11:28:38
|
Glenn, I try to merge and apply your patch on 665-Fix branch this week-end. I quick read your patch and i see this : ! #ifdef PERLWIN32GUI_GLBREAK ! printf("XS(Create): %s\n", perlcs.cs.lpszName ); ! if ( perlcs.cs.lpszName ! && strcmp ( perlcs.cs.lpszName, "findlist.pl Main Window" ) == 0 ) ! { __asm { int 3 }; ! } ! #endif It's a debugger breakpoint !!!!! Some time ago, i search a way to debug a XS code whitout find. It's very usefull, i test it and it's work great with Visual C++. Thank for this "Tip Of The Day" ;o) Laurent. > > Due to my hard drive being in the process of failing, I thought I'd > better get this patch isolated and delivered to you, so that it won't > get lost. Plus maybe Glenn Munroe might be able to use it, and others. > > Here is a description of all the changes I've made, which you can use as > needed as comments in the change log(s). The patch.txt was generated by > diff -r -c against the released version of 0.0.665 sources, not > including any patches you've already applied to the CVS bugfix branch. > I hope that works for you... if it is hard, let me know what I should > provide instead. ... > -- > Glenn |
From: Glenn L. <pe...@ne...> - 2003-11-29 18:22:48
|
On approximately 11/29/2003 3:28 AM, came the following characters from the keyboard of Laurent ROCHER: > Glenn, > > I try to merge and apply your patch on 665-Fix branch this week-end. > > I quick read your patch and i see this : > > ! #ifdef PERLWIN32GUI_GLBREAK > ! printf("XS(Create): %s\n", perlcs.cs.lpszName ); > ! if ( perlcs.cs.lpszName > ! && strcmp ( perlcs.cs.lpszName, "findlist.pl Main Window" ) == 0 ) > ! { __asm { int 3 }; > ! } > ! #endif > > It's a debugger breakpoint !!!!! > Some time ago, i search a way to debug a XS code whitout find. > It's very usefull, i test it and it's work great with Visual C++. > Thank for this "Tip Of The Day" ;o) > > Laurent. Yeah, I took out most (not all) of my debugging code of the nature of #ifdef SOME_SYMBOL_MOST_PEOPLE_WONT_HAVE printf( "something or another\n" ); #endif but when I got to that one, I thought it might be useful for someone that hadn't ever seen it done before. I love debuggers, but they can be real contrary to use with dynamically created code, such as Perl and other interpreters... in such situations, starting from the top, one needs to set a number of breakpoints along the way, after code get created and/or loaded, just to find your way in to where you really want to set the breakpoint. It can often be much easier to instrument the code you want to debug with the breakpoint in the manner above, but unless one understands the assembly language and the debugger itself to some extent, it can be difficult to figure that out! Yes, it does work well with Visual C; some other debuggers, since they did not place the breakpoint there, may get somewhat confused about discovering one there... for those debuggers, often the way they express their confusion is to attempt to "reexecute" the "int 3" instruction. To sidestep their confusion, use the debugger commands to increment the instruction pointer ( reg IP = IP + 1 ) although the syntax varies between debuggers, and sometimes might be click here or there and type the new number (it would be in Visual C, if Visual C didn't handle it reasonably). -- Glenn -- http://nevcal.com/ =========================== Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates And here is why it is ridiculous: The division that includes Windows posted an operating profit of $2.26 billion on revenue of $2.81 billion. --from Reuters via http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html So that's profit of over 400% of investment... with a bit more investment in Windows technology, particularly in the area of reliability, the profit percentage might go down, but so might the bugs and security problems? Seems like it would be a reasonable tradeoff. WalMart earnings are 3.4% of investment. |