Using event handlers - (EasyVENT version 3.2)

[srod]

28th December 2013.
Have added a version which is compatible with Purebasic 5.21, including fixing the OLE drag/drop events (#OnDragItemStart and #OnDropItem).

The download can be found over at the nxSoftware site.

=============================================

23rd October 2008.
Versions for PB 4.2 and 4.3 have now been added to the nxSoftware site. The version for PB 4.3 runs on both x86 and x64 (Windows).

=============================================

12th January 2008. (Purebasic 4.1 onwards). Minor bug fix - version 3.1.3.
A problem with the #OnItemSelected and combo boxes.

Thanks to mrjiles.

The download is HERE

=============================================


2nd January 2008. (Purebasic 4.1 onwards). Minor bug fix - version 3.1.2.
A problem with the #OnItemSelected and ListView gadgets has been fixed. The problem is due to the way PB 4.2 now selects items in such gadgets.
Thanks to mrjiles.


14th October 2007. (Purebasic 4.1 onwards). Minor bug fix - version 3.1.1.
Version 3.1.1 fixes a drag / drop problem which would cause problems on machines running NT 4. Thanks to DoubleDutch.


11th October 2007. (Purebasic 4.1 onwards). Release version 3.1.
Release version 3.1 incorporates all of the 3.0.x betas + the following :

• Code supplied by DoubleDutch (my thanks) to make EasyVENT more compatible with Win 95 (boo!) 98 / ME etc.
• Adjusted the events #OnItemSelected and #OnItemSelecting when used with panel gadgets. The developer is now informed how the user attempted to select a tab (mouse or keyboard etc.)

Anyone coming from earlier versions of EasyVENT who has not kept up with the version 3.0.x betas will need to read through the alterations detailed below regarding these betas as there have been some significant updates / upgrades etc.


23rd September 2007. (Purebasic 4.1 onwards).
Update - version 3.0.2

My apologies, but these rapid adjustments to the EasyVENT library are being driven by my current application; mostly adding extra functionality. Things should settle down pretty soon and for those wishing not to be 'messed around', simply wait for version 3.1 which will be a full release.

I say this because each 3.0.x beta can break existing code, although only in a minor way and depending on the underlying application itself.

I prefer to make these 'minor' upgrades rather than one great big fat one so to give developers a chance to keep up with my adjustments. Indeed I hope this is the last upgrade before version 3.1 which itself will add nothing new.

Version 3.0.2 makes the following ammendments :

• #OnPaint now fires when the application receives #WM_PAINT messages (as before) and #WM_NCPAINT messages (new for beta 3.0.2). Check the value of *sender\uMsg to determine which has caused the event to fire and, for example, if you wish not to process #WM_NCPAINT then call PerformDefaultWinProcessing() and return #EVENT_ReturnDefault.
• For tree gadgets, the events #OnItemSelected and #OnItemSelecting now informs the developer how the user attempted to select the item in question. This is communicated through the 'state' field of the *sender structure. (See the user manual for details).
• A new field has been added to the *sender structure; 'originalmessage' which is used only in #OnUnhandledwinMessage handlers in place of the state field.
• All of the ‘standard’ mouse events (#OnDblClick, #OnMouseDown, #OnMouseOver, #OnMouseUp) have been extended to cover their ‘non-client’ counterparts. That is, the events now fire if the cursor is either over the client or non-client areas of the underlying window\control. The state field of the *sender structure informs the particular event handler if it is the client or non-client area etc.

All of those events which have been extended somewhat have the potential to break existing code because of the need to think about the values returned from the affected handler functions. In most cases, if there is a problem, it will be resolved by simply placing a call to PerformDefaultWinProcessing() and returning #EVENT_ReturnDefault in an appropriate place to account for the extra calls to the handler function.

As usual the user manual is kept fully up to date.

The download link is below.

Regards.


21st September 2007. (Purebasic 4.1 onwards).
Update - version 3.0.1

Version 3.0.1 adds a new event : #OnANYevent, which does exactly what you'd imagine!

It provides a simple way of allowing a single handler to process ALL events (with one exception) for a single Window/control. Kind of like a window procedure, but of course EasyVENT handles all the translation of Win messages and notifications to events etc.

Previously, using a single handler for multiple events required multiple uses of the SetEventHandler() function.

The #OnANYevent handler is thus provided for convenience.

NOTE.
This is a rather 'specialised' event which requires careful processing. You will need to read the relevant sections in the user guide very carefully and study the demo program "OnANYevent demo.pb". This is not to be confused with the #OnUnhandledWinMessage event (which also requires careful handling)!

This event is an application wrecker if you don't use it properly!


20th September 2007. New version of EasyVENT released. (Purebasic 4.1 onwards).
Hi,

I've just completed version 3.0.0 (beta) of EasyVENT which is heaps way more versatile and powerful than earlier versions for one fact and one fact alone (but I'll come to that later).

Unfortunately, and inevitably, EasyVENT 3 is not compatible with earlier versions and thus any source code built around these earlier versions will need some cajouling and beating around the chops with an iron railing before it will behave itself! Actually, I converted all the demo programs within about 20 minutes which means that conversion could be relatively painless. (I'll soon find out though as I have a 12000 line program to convert tomorrow!)

First, for those new to EasyVENT; a quick summary :

EasyVENT is a Purebasic library (written for Windows only) which allows developers to easily attach event handlers to windows/controls/menus etc. for a predefined set of Windows events.

The current list of events is :

#OnButtonClick
#OnChange
#OnClose
#OnCollapseExpandSelection
#OnContextmenuPopup
#OnCursorEnter
#OnCursorExit
#OnDblClick
#OnDragDrop
#OnDragItemStart
#OnDropItem
#OnEditTreeLabels
#OnErase
#OnGotFocus
#OnItemCheckboxChanging
#OnItemSelected
#OnItemSelecting
#OnKeyDown
#OnKeyPress
#OnKeyUp
#OnLinkClick
#OnLostFocus
#OnMaximize
#OnMenuItemSelect
#OnMinimize
#OnMouseDown
#OnMouseOver
#OnMouseUp
#OnMove
#OnPaint
#OnResize
#OnScroll
#OnSetCursor
#OnSizingWindow
#OnUnhandledWinMessage

This new version also fixes some bugs and eradicates a rather dreadful memory leak, but probably adds a whole bunch of extra bugs to track down!

So what is new then?

Well, with earlier versions of EasyVENT, passing the underlying Windows message (if any) back to the system for 'default processing' could only be done after an event handler had finished executing. Now this was a very simple and convenient arrangement, but was quite restrictive in that some situations called out for such processing to occur before the event handler began its work.

This is where EasyVENT 3 steps in. It allows the developer to decide, whilst an event handler is executing, when to call on the system to perform default processing and indeed if at all!

Experienced Windows programmers will quickly realise that this is indeed a lot more flexible; particularly where events related to the mouse and keyboard and scrolling are concerned.

The truth is also that EasyVENT 2 had had too many additions to the code and was beginning to creak and groan under the strain. It was in dire need of a rewrite!

Anyhow, the user manual has been updated and includes a section on upgrading from earlier versions of EasyVENT. The demo programs (which converted across seamlessly) will illustrate the changes in action.

The download is HERE

Expect bugs because this was a big change - even though the code looks a hell of a lot better now! Far neater, easier to follow.

Please note that I will no longer support earlier versions of EasyVENT. Use them by all means, but you're on your own there. I just don't have the time.

Regards.

Stephen.

[DoubleDutch]

Thanks for the new version. I have a large program it EV2 is used in, I'll convert to EV3 tomorrow (later today in fact ) and report any problems (if any).

[DoubleDutch]

Couldn't wait, updated code to new version in about 3 minutes. The only bit I initially got wrong was that in your documentation (page 24) you say put in PerformDefaultWinProcessing() <--- this has no parameter, where it does really need a parameter. No big problem though.

[DoubleDutch]

I messing around with the #OnEditTreeLabels EasyVENT.

Is there anyway that I can change the text in the actual edit box, so I can force uppercase, etc - as it's happening?

[srod]

Hi, thanks for testing. I'm about to start converting my 12000 line application to using EasyVENT 3. It has about 25 handlers to convert!

Couldn't wait, updated code to new version in about 3 minutes. The only bit I initially got wrong was that in your documentation (page 24) you say put in PerformDefaultWinProcessing() <--- this has no parameter, where it does really need a parameter. No big problem though.

A deliberate ommision. I don't actually say that the function has no parameters, I just decided to leave them out of the discussion at that point. The function itself is discussed on page 5.

messing around with the #OnEditTreeLabels EasyVENT.

Is there anyway that I can change the text in the actual edit box, so I can force uppercase, etc - as it's happening

Piece of cake with EasyVENT!

All you do is attach an #OnKeyPress handler to the edit control used to edit the label. I've added a new demo ("Treegadget2 demo.pb") to the EasyVENT download which does exactly this.

Stephen.

**EDIT : yep, my 12000 line app converted across to EasyVENT 3 without a hitch! Took about 10 minutes and it has fixed the problems I was having with this application!

[DoubleDutch]

Code: Select all

 hwnd = SendMessage_(*sender\hwnd, #TVM_GETEDITCONTROL, 0, 0)
SetEventHandler(hwnd, #OnKeyPress, @KeyPress())

I thought it would be something similar to that. I use this (#TVM_GETEDITCONTROL) already to set the text to something different than is actually displayed.

Should be easy to mix it in with what I have already.

Thanks

-Anthony

[srod]

21st September 2007. (Purebasic 4.1 onwards).
Update - version 3.0.1

Version 3.0.1 adds a new event : #OnANYevent, which does exactly what you'd imagine!

It provides a simple way of allowing a single handler to process ALL events (with one exception) for a single Window/control. Kind of like a window procedure, but of course EasyVENT handles all the translation of Win messages and notifications to events etc.

Previously, using a single handler for multiple events required multiple uses of the SetEventHandler() function.

The #OnANYevent handler is thus provided for convenience.

NOTE.
This is a rather 'specialised' event which requires careful processing. You will need to read the relevant sections in the user guide very carefully and study the demo program "OnANYevent demo.pb". This is not to be confused with the #OnUnhandledWinMessage event (which also requires careful handling)!

This event is an application wrecker if you don't use it properly!


Please see the first post for the download link.

[srod]

REMOVED.

[Derek]

Just tried the 'general demo' example and when I come to resize the window with the mouse over gadget in it I only have to click on any of the window edges to activate the resize (not hold down the mousebutton as I would expect) and then I can't stop the resize, even if I drag the cursor out the edge of the window it still keeps resizing, it only stops when I activate another window. Hope I explained that well enough.

I'm using 4.10b2 on XP.

[srod]

Doh!

A case of me not being able to follow my own instructions given in my post above regarding additional calls to PerformDefaultWinProcessing().

Fixed. Could you download again and try the demo.

There may be a couple more of the demos which I haven't adjusted properly.

Thanks.

[Derek]

The general demo seems to be working fine now, very nice it is too.

One small niggle, in the treegadget demo when you try to uncheck the nochange node (number 8 ) you still report the event as an un-check which could be misleading, perhaps a different message could be reported, although I'm guessing that would require a bit of work.

[srod]

The general demo seems to be working fine now, very nice it is too.

One small niggle, in the treegadget demo when you try to uncheck the nochange node (number you still report the event as an un-check which could be misleading, perhaps a different message could be reported, although I'm guessing that would require a bit of work.

Not much work. Altered two lines in the TreeGadget example!

Done.

The thing is though that this isn't an EasyVENT issue, just an issue with this particular example.

The #OnItemCheckboxChanging event of course allows the developer to deny the user permission from altering individual checkboxes in ListIcon or Tree gadget items. When this event fires EasyVENT informs the handler function what it is the user is attempting to do; in this case he/she would be attempting to clear the checkbox.

[Derek]

Ok, I see.

Really nice piece of work though. Hope to use it in some of my programs soon.

[srod]

I've now found a bug in EasyVENT thanks to you pointing me at the general demo so I'm glad you posted.

A fiddly bugger it is as well!


**FIXED.

[srod]

REPOST. -Thanks Derek for testing, leading to a bugfix.

23rd September 2007. (Purebasic 4.1 onwards).
Update - version 3.0.2

My apologies, but these rapid adjustments to the EasyVENT library are being driven by my current application; mostly adding extra functionality. Things should settle down pretty soon and for those wishing not to be 'messed around', simply wait for version 3.1 which will be a full release.

I say this because each 3.0.x beta can break existing code, although only in a minor way and depending on the underlying application itself.

I prefer to make these 'minor' upgrades rather than one great big fat one so to give developers a chance to keep up with my adjustments. Indeed I hope this is the last upgrade before version 3.1 which itself will add nothing new.

Version 3.0.2 makes the following ammendments :

• #OnPaint now fires when the application receives #WM_PAINT messages (as before) and #WM_NCPAINT messages (new for beta 3.0.2). Check the value of *sender\uMsg to determine which has caused the event to fire and, for example, if you wish not to process #WM_NCPAINT then call PerformDefaultWinProcessing() and return #EVENT_ReturnDefault.
• For tree gadgets, the events #OnItemSelected and #OnItemSelecting now informs the developer how the user attempted to select the item in question. This is communicated through the 'state' field of the *sender structure. (See the user manual for details).
• A new field has been added to the *sender structure; 'originalmessage' which is used only in #OnUnhandledwinMessage handlers in place of the state field.
• All of the ‘standard’ mouse events (#OnDblClick, #OnMouseDown, #OnMouseOver, #OnMouseUp) have been extended to cover their ‘non-client’ counterparts. That is, the events now fire if the cursor is either over the client or non-client areas of the underlying window\control. The state field of the *sender structure informs the particular event handler if it is the client or non-client area etc.

All of those events which have been extended somewhat have the potential to break existing code because of the need to think about the values returned from the affected handler functions. In most cases, if there is a problem, it will be resolved by simply placing a call to PerformDefaultWinProcessing() and returning #EVENT_ReturnDefault in an appropriate place to account for the extra calls to the handler function.

As usual the user manual is kept fully up to date.

The download link is at the foot of the first post in this thread.

Regards.