From: Robert M. <rm...@po...> - 2005-07-02 23:56:22
|
In several places in Win32::GUI XS code there are warnings printed. When this happens, there is (as far as I have checked) always test 'if (PL_dowarn)' around the warning. Now, I'm sure there is some Perl history here, as the documentation (perlintern) clearly states that PL_dowarn is the XS programmer's equivalent of $^W. It is not! PL_dowarn is a bitmask that conveys a whole load of global warning state (See perl's warnings.h for more details). The upshot of this is that the *only* way to silence such messages from Win32::GUI is to ensure that you start perl with no warning command line switches (none of -w, -W or -X) and to not have a 'use warnings' line anywhere in your code. {Yes, currently -X on the command line results in Win32::GUI splitting out warnings :-) (you can also use a $SIG{__WARN__} hook, but you need to know the characteristics of the messages you want to silence to do this - see my recent post to the users list). This is obviously an undesirable situation. Using (PL_dowarn & G_WARN_ON) instead is the direct equivalent of checking $^W. The downside of this is that 'use warnings' does not set $^W, and so making this change will result in most current code silencing these warnings. To turn them on you need to use -w, -W (command line) or $^W=1 (in your code). But at least we'd have a way to control whether such messages are emitted. I see 4 possible ways forward: (1) Leave it as it is, and wait for Perl 5.9 which will (from what I read) extend the 'warnings::warnif' mechanism to XSUBS. (2) Change to checking against (PL_dowarn & G_WARN_ON), with the side effects mentioned above, and highlighting the change in release notes/readme. (3) Introduce a package global (Win32::GUI::WARNINGS?) that the user can set to control warnings, defaulting to on (matching the current behaviour) (4) Review the warnings that we have, and decide if they are needed, or if there are other ways to behave. (for example the irritating warnings about -style being deprecated could perhaps be removed, as I think it is a useful option). This route may be orthogonal to the other 3, as we may want to do this anyway, and if we have any warnings left, then we will still need to pick one of the other 3 options. My vote is for (2). Comments? Regards, Rob. Further background: |
From: Robert M. <rm...@po...> - 2005-07-03 22:09:36
|
Glenn Linderman wrote: > On approximately 7/2/2005 4:56 PM, came the following characters from > the keyboard of Robert May: > >> In several places in Win32::GUI XS code there are warnings printed. >> >> When this happens, there is (as far as I have checked) always test >> 'if (PL_dowarn)' around the warning. Now, I'm sure there is some >> Perl history here, as the documentation (perlintern) clearly states >> that PL_dowarn is the XS programmer's equivalent of $^W. It is >> not! PL_dowarn is a bitmask that conveys a whole load of global >> warning state (See perl's warnings.h for more details). The upshot >> of this is that the *only* way to silence such messages from >> Win32::GUI is to ensure that you start perl with no warning command >> line switches (none of -w, -W or -X) and to not have a 'use warnings' >> line anywhere in your code. {Yes, currently -X on the command line >> results in Win32::GUI splitting out warnings :-) (you can also use a >> $SIG{__WARN__} hook, but you need to know the characteristics of the >> messages you want to silence to do this - see my recent post to the >> users list). >> >> This is obviously an undesirable situation. >> >> Using (PL_dowarn & G_WARN_ON) instead is the direct equivalent of >> checking $^W. The downside of this is that 'use warnings' does not >> set $^W, and so making this change will result in most current code >> silencing these warnings. To turn them on you need to use -w, -W >> (command line) or $^W=1 (in your code). But at least we'd have a >> way to control whether such messages are emitted. >> >> I see 4 possible ways forward: >> >> (1) Leave it as it is, and wait for Perl 5.9 which will (from what I >> read) extend the 'warnings::warnif' mechanism to XSUBS. >> >> (2) Change to checking against (PL_dowarn & G_WARN_ON), with the side >> effects mentioned above, and highlighting the change in release >> notes/readme. >> >> (3) Introduce a package global (Win32::GUI::WARNINGS?) that the user >> can set to control warnings, defaulting to on (matching the current >> behaviour) >> >> (4) Review the warnings that we have, and decide if they are needed, >> or if there are other ways to behave. (for example the irritating >> warnings about -style being deprecated could perhaps be removed, as I >> think it is a useful option). This route may be orthogonal to the >> other 3, as we may want to do this anyway, and if we have any >> warnings left, then we will still need to pick one of the other 3 >> options. >> >> My vote is for (2). Comments? > > > Not clear that I understand the various Perl warning mechanisms you > describe to comment effectively. I'm not surprised. They are complex, and not well documented. It's taken we most of the week to get my current (very poor) understanding of how it all works. I'm entering a busy spell at work, so I'm not sure exactly when, but I'll try to find time to write up my understanding a bit better at a later date. Here are a couple of threads that seem to be the information 'from the horses mouths', so to speak. They're pretty impenetrable, and I put the link here more so that I can find them later, than because I think they are a good read. http://groups.google.co.uk/group/perl.perl5.porters/browse_thread/thread/5638f7d32139d3a4/368fb93c71813e02?q=lexical+warnings+XSUB&hl=en#368fb93c71813e02 http://groups.google.co.uk/group/perl.perl5.porters/browse_thread/thread/d26aec8d5376d9ca/e2713a92344a5df9?q=lexical+warnings+XSUB&rnum=5&hl=en#e2713a92344a5df9 > > I do "use warnings" and "-w" in most of my code, and all is well for > me, and I get lots of diagnostics... And I haven't had any major > problems coding around the existing warnings, such that my code > doesn't cause warnings to occur. So (1) seems acceptable to me. > > I don't understand the side effects of (2). There would be no change for you. The change would be for anyone who doesn't use '-w' - Win32::GUI's warnings would stop appearing, as there is no way to reliably check from XS what the 'use warnings' settings in the caller's scope are set to. > > (3) seems too specific to this module. Indeed. But not having a way to turn off warnings in production code is an issue, isn't it? > > (4) A review of warnings is certainly not a bad thing... but proposed > changes should be entertained with caution. -style is "easy" but I > think the theory under which it was deprecated is that it can be too > easily used to turn off things that default to on, that you might not > know about. This is because (I think) of the way that Microsoft > introduces more options, some of which are on. So adding and removing > specific options seems better, according to that theory. Right, I understand why -style is dangerous. But without it you have to have knowledge of what styles Win32::GUI uses by default so that you can pop the ones you don't want, and add the ones that you do want. In the case where you know exactly what styles you want it is equally dangerous to use pop and push in a module, as any changes to the default styles used by Win32::GUI may break your code. But I'm wandering off topic with this specific example. Regards, Rob. |
From: Jeremy W. <jez...@ho...> - 2005-07-04 08:52:37
|
Hi, Was looking at something else and came across the -container option. What is it for? The option has no documentation, but does seem to do "something". It has a message loop (ContainerMsgLoop in GUI_MessageLoops), and a constant (PERLWIN32GUI_CONTAINER) which is checked/used in several places. If anyone can provide an explanation - and perhaps an example:) I'll update the docs. Cheers, jez. |
From: Robert M. <rm...@po...> - 2005-08-03 22:39:47
|
Jeremy White wrote: > Hi, > > Was looking at something else and came across the -container option. > What is it for? The option has no documentation, but does seem to do > "something". It has a message loop (ContainerMsgLoop in > GUI_MessageLoops), and a constant (PERLWIN32GUI_CONTAINER) which is > checked/used in several places. > > If anyone can provide an explanation - and perhaps an example:) I'll > update the docs. I've had a look at the code, and can tell you what it does, but I can't tell you why it's useful. The -container option set the PERLWIN32GUI_CONTAINER flag against an object. See ParseWindowOptions in GUI_Options.cpp: } else BitmaskOption("-container", perlcs->dwPlStyle, PERLWIN32GUI_CONTAINER) It is used in the ControlMessageLoop (the window procedure that is by default used to sub-class controls), and passes all unprocessed WM_COMMAND and WM_NOTIFY messages the objects parent. Search for PERLWIN32GUI_CONTAINER in GUI_Messageloops.cpp The flag is automatically set in Create() on the parent of any window or control that is not itself a window(Window, DialogBox, MDIFame, MDIClient) So there you go. I can't think of a use for it. Rob. |
From: Johan L. <johanl@DarSerMan.com> - 2005-09-29 10:45:28
|
At 08:44 2005-09-29, Glenn Linderman wrote: >Does this have anything to do with grouping radio buttons into separate >containers so that they can turn each other on/off, so that only one is on >at a time? To have multiple groups of radio buttons in a window, one >needs to have them in separate containers. But maybe this is just a >terminology redundancy that is confusing me? No, that's not how it works. You set the -groupstart => 1 for the first RadioButton in each group of them. /J -------- ------ ---- --- -- -- -- - - - - - Johan Lindström Sourcerer @ Boss Casinos johanl AT DarSerMan.com Latest bookmark: "TCP Connection Passing" http://tcpcp.sourceforge.net/ dmoz: /Computers/Programming/Languages/JavaScript/ 12 |