Hi,
> The only quibble I have then, is that when you said you committed my
> patch, that opens the door for confusion ... because people saw my patch
> on-line. And then, when we coordinate other patches (like the
> accelerator keys) there would be surprises in the diffs.
>
> So, I think it would
It's look nice, but it's more a new feature than a Fix ;o)
So, i want to know if Aldo have plan for File Drag&Drop in next release.
And, if he want to use a separate .pm file with Win32::API dependance or add
it directly in GUI.xs code.
I ask this only for keep compatibility with next version.
L
I agree
- Original Message -
From: "Laurent ROCHER" <[EMAIL PROTECTED]>
To: "Steve Pick" <[EMAIL PROTECTED]>; "Win32 GUI Hackers"
Sent: Friday, November 21, 2003 6:31 PM
Subject: Re: [perl-win32-gui-hackers] Fix for PeekMessage
>
> For "A" problem, i don't think it's a else problem.
>
Yes, this looks better to me too. For whatever my opinion is worth.
On approximately 11/21/2003 10:31 AM, came the following characters from
the keyboard of Laurent ROCHER:
For "A" problem, i don't think it's a else problem.
You can call PeekMessage without a message parameter.
In this case
Hi Laurent,
Indeed, your revisions to my patch are better than my original... and
with your revision, Steve's extra line of code isn't needed (and it
concerned me that he was picking a particular cursor shape... that
sounded wrong, but I had no clue what would be right). And you cleaned
out
For "A" problem, i don't think it's a else problem.
You can call PeekMessage without a message parameter.
In this case message == &PL_sv_undef, and no warming it's necessary.
If you specify a message parameter, then we need a reference (SvROK) and
must be a Array reference.
I think it's better to
Hi,
I haven't commit exact Glenn patch.
I have commmit this :
case WM_SETCURSOR:
{
WORD nHitTest = LOWORD( lParam );
if( nHitTest == HTCLIENT ) { // only diddle cursor in client
areas
LPPERLWIN32GUI_USERDATA perlud;
perlud = (LP
7 matches
Mail list logo
