Que es esto Scintilla?
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, December 04, 2005 10:34 PM
To: [email protected]
Subject: [SPAM-MAIL ] - Perl-Win32-GUI-Hackers digest, Vol 1 #239 - 2
msgs - Found word(s) remove list list error in the Text body
Send Perl-Win32-GUI-Hackers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Perl-Win32-GUI-Hackers digest..."
Today's Topics:
1. Re: Fixing Scintilla (Robert May)
2. Perl contexts [Was: Fixing Scintilla] (Robert May)
--__--__--
Message: 1
Date: Sun, 04 Dec 2005 19:16:34 +0000
From: Robert May <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Organization: At Home
To: Jeremy White <[EMAIL PROTECTED]>
CC: [email protected]
Subject: [perl-win32-gui-hackers] Re: Fixing Scintilla
Jeremy White wrote:
> I'm trying to fix Scintilla, with the aim of creating a new release of
> this module. The problem is that Scintilla defines and uses it's own
> PERLWIN32GUI_USERDATA structure. As this structure has changed over
time
> in Win32-GUI it creates all kinds of problems with this module
> (Scintilla subclasses Win32-GUI, and uses the PERLWIN32GUI_USERDATA
> structure passed to it by Win32-GUI). The most extreme behaviour is
> with perl 5.8.x where the Scintilla does not process events - there is
> also cases where Scintilla crashes.
>
> I've managed to get a build of Scintilla working, but I've got several
> issues. Instead of defining it's own version of PERLWIN32GUI_USERDATA
it
> now picks it up from GUI.h - which I think is the best solution (?).
>
> 1) The original Scintilla:
>
> #include "EXTERN.h"
> #include "perl.h"
> #include "XSUB.h"
>
> #include <windows.h>
> #include "./include/Scintilla.h"
>
> changed to:
>
> #include "../Win32-GUI/GUI.h"
> #include "./include/Scintilla.h"
>
> However, when compiling with VC I get two errors:
>
> *** Using Preserved Perl context.
>
> ../Win32-GUI/GUI.h(439) : error C2143: syntax error : missing ')'
before
> '='
> ../Win32-GUI/GUI.h(439) : error C2072: 'DoHook' : initialization of a
> function
> ../Win32-GUI/GUI.h(439) : error C2059: syntax error : ')'
> ../Win32-GUI/GUI.h(809) : error C2059: syntax error : 'string'
> NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code
> '0x2'
> Stop.
>
> this is with the line:
>
> void DoHook(NOTXSPROC LPPERLWIN32GUI_USERDATA perlud, UINT uMsg,
WPARAM
> wParam, LPARAM lParam, int* PerlResult, int notify = 0);
>
> removing " = 0" fixes that issue.
At first glance these errors look like C++ vs. C syntax problems. I
haven't looked at the scintilla code, but it would be my guess that the
XS files is being compiled as C (this is the standard Makefile.PL
behaviour) whereas Win32::GUI (for reasons that escape me) is built
using a C++ compiler (see the override in Win32::GUI's Makefile.PL (sub
xs_c) that builds .cpp files from the XS rather than .c files).
There are 2 approaches: (1) add the same override to Scintilla to get it
to make .cpp files from the .xs, forcing the compilers into c++ mode,
(2) Fix up the Win32::GUI GUI.h file to work correctly with a standard C
compiler.
I thin that (2) if preferable, and it is one of my longer-term goals to
get Win32::GUI to use standard 'C' too.
Standard 'C' does not allow defaulting of function parameters in the
prototype, so my solution here would be to remove the "= 0" from GUI.h,
and modify the 2 calls to DoHook() in GUI_MessageLoops.cpp that don't
pass the last parameter to pass 0 explicitly.
> The second error:
>
> *** Using Preserved Perl context.
>
> ../Win32-GUI/GUI.h(809) : error C2059: syntax error : 'string'
> NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code
> '0x2'
> Stop.
>
> this is with:
>
> extern "C" BOOL WINAPI
> GetWindowInfo(
> HWND hwnd,
> PWINDOWINFO pwi
> );
>
> Commenting out this code removes the error.
My fix would be to replace that code with
#ifdef __cplusplus
extern "C"
#endif
BOOL WINAPI GetWindowInfo(
HWND hwnd,
PWINDOWINFO pwi
);
> 2) I'm confused about the Perl context and how it's used within
> Win32-GUI - and how Scintilla should handle things.
>
> I've got it working by doing:
>
> dTHX; /* fetch context */
>
> in the Scintilla event handlers, but had to remove NOTXSCALL/NOTXSPROC
> in some functions where the context isn't used/needed.
>
> If it would help, I can check in what I've got, with the idea of
fixing
> things once I've got my head around these issues?
I'm not overly familiar with this, but the concept is that a call to a C
function that doesn't require perl context should look like a regular
C call; A call from an XS sub (or anywhere that has a perl context
pointer available) to a function that requires a perl context should be
defined with a first argument of NOTXACALL/NOTXSPROC macro (but with no
following comma). These macros defined the correct type of argument to
pass the perl context. I can do more investigation and expand on this
if necessary.
Regards,
Rob.
--__--__--
Message: 2
Date: Sun, 04 Dec 2005 20:21:24 +0000
From: Robert May <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Organization: At Home
To: [email protected]
CC: Jeremy White <[EMAIL PROTECTED]>
Subject: [perl-win32-gui-hackers] Perl contexts [Was: Fixing Scintilla]
>> 2) I'm confused about the Perl context and how it's used within
>> Win32-GUI - and how Scintilla should handle things.
>>
>> I've got it working by doing:
>>
>> dTHX; /* fetch context */
>>
>> in the Scintilla event handlers, but had to remove
NOTXSCALL/NOTXSPROC
>> in some functions where the context isn't used/needed.
>>
>> If it would help, I can check in what I've got, with the idea of
>> fixing things once I've got my head around these issues?
>
>
> I'm not overly familiar with this, but the concept is that a call to a
C
> function that doesn't require perl context should look like a regular
C
> call; A call from an XS sub (or anywhere that has a perl context
> pointer available) to a function that requires a perl context should
be
> defined with a first argument of NOTXACALL/NOTXSPROC macro (but with
no
> following comma). These macros defined the correct type of argument
to
> pass the perl context. I can do more investigation and expand on this
> if necessary.
OK, I've just scanned the perldoc perlguts section entitled "How
multiple interpreters and concurrency are supported". I think it's
reasonable to assume the following:
You can always define PERL_NO_GET_CONTEXT - all modern perl's will
behave with this regardless of whether PERL_IMPLICIT_CONTEXT is defined
or not (although it is defined for current ActiveState Perl builds -
it's required for ithread support). Defining pTHX, pTHX_, aTHX, aTHX_
and dTHX are dealt with in perl.h and XSUB.h
In Win32::GUI NOTXSPROC and NOTXSCALL are aliases for pTHX_ and aTHX_
respectively. Any other code in GUI.h is purely for backwards
compatibility with older perl's. Even the "\n*** Using an implicit Perl
context.\n" section should not be necessary, as pTHX_ and aTHX_ should
deal with non-thread-capable perl builds.
To understand how to use pTHX_ and aTHX_ correctly read perlguts - but
for consistency with Win32::GUI I would recommend using NOTXSPROC and
NOTXSCALL macros in their place.
[ I've added a note to myself to look for all the places that we use
dTHX and to ensure that they are necessary - I think they are used when
we get a win32 api callback such that we can't use the NOTXSPROC calling
convention ]
I hope this helps.
Rob.
--__--__--
_______________________________________________
Perl-Win32-GUI-Hackers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
http://perl-win32-gui.sourceforge.net/
End of Perl-Win32-GUI-Hackers Digest
