perl-win32-users archive @ ASPN

RE: $# and %s Crashing Perl V5.8.7

[resending because the first attempt
was blocked]

> -----Original Message-----
> From: Jan Dubois [mailto:jand@...
> Sent: June 21, 2006 5:38 PM
> To: 'Veli-Pekka Tätilä'; 'Perl-Win32-Users@...
> Subject: RE: $# and %s Crashing Perl V5.8.7
> 
> On Wed, 21 Jun 2006, Veli-Pekka Tätilä wrote:
> > Hi, Browsing perlvar the other day, I noticed a deprecated variable
> > called $# controlling the printing of floating point values.
> 
> Note that the code supporting $# has been removed in the Perl development tree; it will
not be
> available in Perl 5.10 anymore.
> 
> Cheers,
> -Jan



_______________________________________________
Perl-Win32-Users mailing list
Perl-Win32-Users@...
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: $# and %s Crashing Perl V5.8.7

Joe Discenza wrote:
> "Veli-Pekka Tätilä" wrote, on Wednesday, June 21, 2006 1:54 PM
>> $# = '%s'; # But an invalid format.
>> print $pi; # crashes the interpreter.
>> I'm running Active State Perl v5.8.7 build 815 [211909].
> I just tested this with build 638, also XP Pro SP2, with the same results.
Ah good to know. I did some further testing with the Uni machine and seems
this isn't WIn32 specific at all.
paju:(~)(57)% perl

Segmentation fault
paju:(~)(60)% uname -a
SunOS paju 5.10 Generic_118822-27 sun4u sparc SUNW,Netra-T12
paju:(~)(61)% perl -v

This is perl, v5.8.4 built for sun4-solaris-64int
(with 27 registered patches, see perl -V for more detail)


-- 
With kind regards Veli-Pekka Tätilä (vtatila@...
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila/

_______________________________________________
Perl-Win32-Users mailing list
Perl-Win32-Users@...
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

$# and %s Crashing Perl V5.8.7

Hi,
Browsing perlvar the other day, I noticed a deprecated variable called $# 
controlling the printing of floating point values. The examples I found of 
its usage hinted at sprintf style formatting and in fact it appears to work 
oK. However, I got curious enough to try out format chars other than g with 
disastrous results. I do admit that playing with a deprecated variable in an 
unintended manner is sort of asking for trouble, but I didn't expect the 
whole perl interpreter to crash without any debug messages.

Here's the code which runs fine till the last print statement, and even has 
time to nag about the $# variable.

use strict; use warnings;
my $pi = 3.141592; # some double value.
local $\ = "\n";

local $# = "%+.3g"; # Normal usage.
print $pi; # works fine.

$# = '%s'; # But an invalid format.
print $pi; # crashes the interpreter.

I mainly posted this to find out more on Why it crashes, just out of 
curiosity. If there's something wrong with a regular printf it rarely causes 
this bad results in my experience. So, I wonder why $# is so fatal.

I'm running Active State Perl v5.8.7 build 815 [211909]. The OS is XP Pro 
SP2 with all the latest fixes and this is an HP & Compaq NX8220 laptop, in 
case it has any relevance.

-- 
With kind regards Veli-Pekka Tätilä (vtatila@...
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila/ 

_______________________________________________
Perl-Win32-Users mailing list
Perl-Win32-Users@...
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: WMI Asynchronous Calls

I would speed it up my making it
multithreaded.	This is really pretty easy.
Read up on the threads pragma in the docs.  U could then do 10 or 20
simultaneously no problem.

something like:
threadlimit = 10;
while (threads < threadlimit) {
	last unless @...
	async(dosomething);
}
sub dosomething {
	threads++;
	pop @...
	do work
	threads--;
}


At 11:01 AM 6/21/2006 +0100, Paul Sobey wrote:
>I have a script which restarts services on around 400 clients. At the
>moment, the script connects to WMI on each machine separately and calls
>Win32_Service->StopService(), followed by Win32_Service->StartService().
>
>I'd like to speed it up a bit and thought of using the WMI asynchronous
>providers to group a whole load of stop() requests, followed by a whole
>load of start requests, but I confess I have no idea where to start. Does
>anybody have any sample code or pointers to offer?






--
REMEMBER THE WORLD TRADE CENTER 	---=< WTC 911 >=--
"...ne cede malis"

00000100

_______________________________________________
Perl-Win32-Users mailing list
Perl-Win32-Users@...
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Cross-Domain Group Membership

Hi all...

I'm trying to figure out the best (read: fastest) way to collect local
domain group membership information for users in other trusted domains in
our forest... I'm trying to figure out if I can impersonate as the outside
domain user in my local domain and collect groups from the login token... or
what...

I know that the "memberof" attributes won't be populated in the directory
for user:  dom2\user ... with information from dom1 ... so I can't get it
from there...

Has anyone done anything like this?  Thoughts?

Thanks,

Andy Speagle

Re: Wide character Filename in Perl 5.8

The "wide_system_calls" option was
intentionally disabled in Perl 5.8. See 
the following posting from Jan Dubois.

http://aspn.activestate.com/ASPN/Mail/Message/perl5-porters/2933666


There are two work arounds to this problem. 

(1)  Use the "FileSystem.Scripting"  OLE object as referenced in the 
following posting also by Jan Dubois.

http://aspn.activestate.com/ASPN/Mail/Message/perl5-porters/2933843


(2) Use my ugly code that effectively does what the "wide_system_calls" 
option did:  use the Win32 API wide versions (instead of the ANSI 
versions) of the directory search functions FindFirstFileW and 
FindNextFileW.

http://aspn.activestate.com/ASPN/Mail/Message/2996684



Regards,

... Dewey





"Sean Lin"

WMI Asynchronous Calls

I have a script which restarts
 on around 400 clients. At the
moment, the script connects to WMI on each machine separately and calls
Win32_Service->StopService(), followed by Win32_Service->StartService().

I'd like to speed it up a bit and thought of using the WMI asynchronous
providers to group a whole load of stop() requests, followed by a whole
load of start requests, but I confess I have no idea where to start. Does
anybody have any sample code or pointers to offer?

Cheers,
Paul


_______________________________________________
Perl-Win32-Users mailing list
Perl-Win32-Users@...
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Wide character Filename in Perl 5.8

Why ${^WIDE_SYSTEM_CALLS}=1 no effect
in Perl 5.8? 
But in 5.6 normal.


use utf8;

${^WIDE_SYSTEM_CALLS} = 1;

foreach ( glob("*.*") ) {
   print "$_\n";
}

Re: Calling SetWindowsHookEx()?

Lyle Kopnicky wrote:
> It appears the code only needs to be in a DLL if you want to create a
> system level hook. I only need a thread level hook.
Correct, to my knowledge at least. I wass thinking of system wide hooks 
mainly and failed to point that out. So I suppose your Perl solution should 
work.

> Listed below is what I have so far. It waits for a few seconds, then 
> quits. 
OK I took a quick glance at it and a couple of more or less trivial 
questions and observations came to mind.

The MSDN docs state specifically that if the hook code is negative, no 
processing should be done except to pass on the parameters to CallNextHookX 
and return its return value. I suppose it doesn't really matter here but 
that's one minor detail of the "hook contract", which your testing code 
violates.

Also the question of how to get the HINSTANCE and ThreadId parameters using 
Perl has been bothering me, too. Are you sure that the GetCurrentThreadId 
function you import from kernel32 does get the same thread in which your 
application actually runs? I suppose Perl might be multi-threaded, am not 
certain about this, though, or some of the TK or Win32 stuff might have some 
event handling threads. I know next to nothing about how those modules are 
implemented, these are just wild guesses. I do know Java has multiple 
threads running starting from the garbage collector, which caused me to 
extrapolate here.

Finally, where did you get the magic number for the low-level keyboard hook? 
Are you sure its correct? Silly question, I know, but sometimes silly things 
do happen (like mistyping JDBC as JBDC and wondering why things don't work). 
My oldish MSDN collection says, by the way, that low-level keybord hooks are 
only supported in NT. You aren't running Win 9X by any chance, are you?

> If I change the return type of SetWindowsHookEx from 'P' to 'N', my
> main window will open, but I still don't get any calls to KeyboardHook.
Umm, the fact that changing the prototype affects program behavior here 
might be a sign of a wrong prototype. I've only imported very basic 
functions with Win32::API so far, so I cannot be of much help with Perlish 
callbacks to Win32 functions, I'm afraid.

Your code:
use warnings;
use strict;
use Tk;
use Win32::API;
use Win32::API::Callback;

my $WH_KEYBOARD_LL = 13;

my $GetCurrentThreadId
   = new Win32::API('kernel32', 'GetCurrentThreadId', '', 'N');
my $SetWindowsHookEx =
   new Win32::API('user32', 'SetWindowsHookEx', 'NKPP', 'P');
Win32::API->Import('user32', 'HHOOK SetWindowsHookEx(int idHook,
HOOKPROC lpfn, HINSTANCE hMod, DWORD dwThreadId)');
my $CallNextHookEx =
   new Win32::API('user32', 'CallNextHookEx', 'PNNN', 'N');

sub KeyboardHook($$$) {
   my ($nCode, $wParam, $lParam) = @...

   print "nCode=$nCode, wParam=$wParam, lParam=$lParam\n";
   $CallNextHookEx->Call(0, $nCode, $wParam, $lParam);
}

my $KeyboardHookCallback =
   new Win32::API::Callback(\&KeyboardHook, 'NNP', 'N');
my $ThreadId = $GetCurrentThreadId->Call();
my $Hook = $SetWindowsHookEx->Call($WH_KEYBOARD_LL, $KeyboardHookCallback,
   0, $ThreadId);

my $win = MainWindow->new();
MainLoop();
End code.

-- 
With kind regards Veli-Pekka Tätilä (vtatila@...
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila/ 

_______________________________________________
Perl-Win32-Users mailing list
Perl-Win32-Users@...
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs



RE: ANNOUNCE: Beta of PPM version 4 released
Hi Teddy,

I have discussed the Tcl/Tk accessibility issues with Jeff Hobbes (the
Tcl guy who added the original accessibility support to Tk). He said Tk
currently only supports MSAA 1.0, but the latest screen readers require
the MSAA 2.0 functionality.

I'll help him to look into this issue eventually, but don't know when
we'll find time to do this. It may not happen until after the PPM4 GUI
is released. As a side effect this should also make Tk (and Tkx)
programs more accessible on Tablet PCs because the Tablet Input Panel
piggybacks on MSAA 2.0 to hook in the alternate input methods.

Cheers,
-Jan

PS: I hope you don't mind that I've copied perl-win32-users back into
    this thread, as I don't think it needs to be a private discussion.

On Sat, 17 Jun 2006, Octavian Rasnita wrote:
> Hi,
>
> As a feedback, I have installed TCL (latest version), Tkx perl module
> and I have tried the sample tkxed program.
>
> Jaws, the most used screen reader, and the Narrator (the Windows
> included screen reader) can read just the title bar in this
> application.
>
> I have seen that the menus are read well in the menus sample
> application.
>
> I have tried creating a sample button using the sample code from the
> POD documentation but the interface was not accessible. I don't know,
> maybe TCL/Tkx needs adding some parameters when creating the window
> and the controls in order to make them usable with a keyboard and no
> mouse. (like Win32::GUI needs adding -dialogui => 1 for windows, and
> -tabstop for form controls)...
>
> Or maybe the TCL/Tk original library is still not accessible for
> screen readers yet... I don't know, but I still hope it is.
>
> Thank you.
>
> Teddy
>
On Fri, 16 Jun 2006, "Jan Dubois"  > On Fri, 16 Jun 2006, Octavian Rasnita wrote:
> > > Thanks for ppm4, but...
> > >
> > > Will we still be able to use the command line mode of ppm4 after
> > > the GUI will be ready? This is very important, because the Tk
> > > library is not accessible at all for screen readers.
> >
> > Yes, the commandline mode will always be available. You'll only
> > invoke the GUI if you don't specify any commandline arguments to ppm
> > at all.
> >
> > So in a sense the GUI replaces the "subshell mode" of ppm, which was
> > a bad idea in the first place. Note that ppm still remembers the
> > results of e.g. a search command, so you can still use it to install
> > a specific package from the search results:
> >
> >	ppm search Win32 ppm install 17
> >
> > To install the 17th module from the list. But for command history
> > etc. you now use your normal shell instead of the ppm3
> > implementation.
> >
> > Please also note that the ppm GUI will not use PerlTk, but the Tcl
> > and Tkx modules, which have access to the very latest Tk
> > implementations of themed widgets etc. Tcl/Tk is supposed to work
> > with at least the Microsoft screen reader. So please let us know if
> > the PPM GUI in Beta 2 is not accessible with screen readers and I'll
> > try to figure out what is happening. But I suspect that the
> > commandline version will always be easier for screen reader usage.
> >
> > Cheers,
> > -Jan



_______________________________________________
Perl-Win32-Users mailing list
Perl-Win32-Users@...
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs