OpenEuphoria

1. RE: onEvent, lparam structure parsing.

• Posted by Matthew Lewis <matthewwalkerlewis at YAHOO.COM> Nov 12, 2001
• 409 views

> -----Original Message-----
> From: euman at bellsouth.net [mailto:euman at bellsouth.net]

> > Greetings!
> >
> > I have a question about recieving information from a 
> WM_NOTIFY message. I
> am
> > creating a wrapper around a control and it sends lots of 
> information via
> the
> > WM_NOTIFY message. All of it's information via the WM_NOTIFY message
> > contains the real stuff on lParam. On lParam is has a structure, and
> inside
> > the structure is another structure that contains the actual 
> message. The C
> > structures look like:
> >
> > struct NotifyHeader {
> >     // hwndFrom is really an environment specifc window 
> handle or pointer
> >     // but most clients of Scintilla.h do not have this 
> type visible.
> >     file://WindowID hwndFrom;
> >     void *hwndFrom;
> >     unsigned int idFrom;
> >     unsigned int code;
> > };
> >
> 
> constant NMHDR_hwndFrom = 0,
>              NMHDR_idFrom = 4,
>              NMHDR_code = 8,
>              SIZEOF_NMHDR = 12
> 
> 
> ...in WinProc(atom hwnd, atom iMsg, atom wParam, atom lParam)
> 
>     elsif iMsg = WM_NOTIFY then
>           id = peek4s(lParam + NMHDR_hwndFrom)
> 
> id would = the control that is sending the notification to 
> the parent...
> 
> as for the stuff you have below, you'll need to grab a copy 
> of the SDK and
> start reading. Making this work with win32lib is going be a trick!

I would agree, but the sticking point won't be win32lib, but the structures
themselves (I've spent more hours pulling my hair out from incorrectly used
structures--my fault--than anything else).  If you're working with Windows,
and can't find a bug, check your structures again, because it's really easy
to declare one incorrectly.

I wouldn't worry too much about the SDK, since it looks like this is from
something other than a Windows DLL.  The SCNotification structure will have
as its first 16 bytes the NMHDR structure that Euman writes about above.
The rest will start at an offset of 16, and proceed from there.

struct SCNotification {
    struct NotifyHeader nmhdr;

    int position;   // SCN_STYLENEEDED, SCN_MODIFIED, SCN_DWELLSTART,
SCN_DWELLEND
    // position = + 16

    int ch;     // SCN_CHARADDED, SCN_KEY
    // ch = + 20

    int modifiers;  // SCN_KEY
    // ch = + 24
    // etc...
    int modificationType;   // SCN_MODIFIED
    const char *text;   // SCN_MODIFIED
    int length;     // SCN_MODIFIED
    int linesAdded; // SCN_MODIFIED
    int message;    // SCN_MACRORECORD
    uptr_t wParam;  // SCN_MACRORECORD
    sptr_t lParam;  // SCN_MACRORECORD
    int line;       // SCN_MODIFIED
    int foldLevelNow;   // SCN_MODIFIED
    int foldLevelPrev;  // SCN_MODIFIED
    int margin;     // SCN_MARGINCLICK
    int listType;   // SCN_USERLISTSELECTION
    int x;          // SCN_DWELLSTART, SCN_DWELLEND
    int y;      // SCN_DWELLSTART, SCN_DWELLEND
};

So, to get at SCNotification.x:

x = peek4s( lparam + 76 )

It's actually more useful to declare a win32lib structure, so you could
simply use fetch and store, and let win32lib handle offsets for you.  Take a
look at the docs and at how win32lib actually uses structures.  It's really
quite useful once you get the hang of it.

Matt Lewis