 |
KiXforms
The Forum for the KiXforms Community
|
|
| View previous topic :: View next topic |
| Author |
Message |
Shawn
KiXforms Developer
Joined: 22 Feb 2003
Posts: 1983
Location: Canada
|
 Posted: Fri Jan 13, 2006 10:33 pm Post subject: Registry Editor (Readonly) using new Event Strategy |
 |
|
Im working on a REGEDIT look-alike using Kixforms.NET ... the purpose is to test-out the new event strategy that was introduced in the latest development build ... basically here is a quick run-down of that...
In .net, an event gets called directly by the .net library - and there are "event arguments" that are automatically passed to the event function. In .net, an event looks something like this:
| Code: |
Public Sub KeyDown(ByVal sender As Object, ByVal e As KeyEventArgs)
' Your event code here ...
End Sub
|
The event function gets passed an Object that is the "sender" of the event, and it gets passed an object that derives from EventArgs - that contains any "data" that goes with the event (for example, a KeyDown event passes a KeyEventArgs object that contains the KeyCode of the key that went down). Up until now, events in Kixforms.Net were handled like this:
| Code: |
Function KeyDown()
$sender = <the object you assumed sent the event>
$e = $sender.KeyDownEventArgs
; Your event code here...
EndFunction
|
Basically the sender you have to figure out yourself (its usually not too hard if you only got one object triggering the event). And the arguments to the event I encoded in special (non standard) properties named after the event itself (ie, KeyDown has KeyDownEventArgs. KeyUp has KeyUpEventArgs) and the EventArgs resided inside the sender.
Well ... here is the new (more .netty way) of handling events in Kixforms.NET
| Code: |
Function KeyDown()
$sender = $System.Sender
$e = $System.Event
; Your event code here, for example ...
?"KeyCode = " $e.KeyCode
EndFunction
|
So the sender of the event is available from the System.Sender property, and the specific EventArgs that goes with the event is found in System.Event ... having said that, one can (and I've done) setup something that works almost identically to the way .net works. Here's how:
Setup your call to the event like this:
| Code: |
$Form.KeyDown = "FormKeyDown($$System.Sender, $$System.Event)"
|
The event function gets setup like this:
| Code: |
Function FormKeyDown($sender, $e)
; Your event code here for example ...
?"KeyCode = " $e.KeyCode
EndFunction
|
The other kinda cool thing is that .net has whats called "Event Signatures" - basically its the way an event function gets called and what parameters get passed (how it looks). In .net, the signature for event function calls are always the same (eg, they get passed two parameters - the sender and an eventargs). Using this strategy, the same can be said for Kixforms ... all your event functions can take-on the following "signature":
| Code: |
Function FunctionName($sender, $e)
; Your event code here ...
EndFunction
|
And no matter what event your using - the signature for it is always the same. The only thing that will differ is the actual "EventArgs" that gets passed in $e.
Please find attached the REGEDIT look-alike script. Its a work-in-progress - nothing ground-breadking here - been done more than a few times in the past ...
If you want to see a "working with EventArgs" example, check-out the TreeView_BeforeExpand event function. In there, a check is done to see if one is trying to expand the HKEY_CLASSES_ROOT key ... because this key is rather large and because expanding it can take maybe five or ten seconds depending, I disallow expanding that key ... here is the code:
| Code: |
$node = $e.Node
If $node.Text = "HKEY_CLASSES_ROOT"
$= $System.MessageBox.Show("Expanding HKEY_CLASS_ROOT has been disabled")
$e.Cancel = 1
Return
Endif
|
Basically, for this particular event $e points to a TreeViewCancelEventArgs object, and that object has a Cancel property. Coming into the function the value is set to false (dont cancel the expand). But you can set it to TRUE to cancel it - and thats what is done.
Anways, still working on this "event strategy" - its a wip - Instead of System.Event I would have liked to called it System.EventArgs ... there is a reason why I probably shouldn't call it that but still thinking about it.
Anyways looking for discussion, comments and feedback - positive and negative. Dont be shy about.
BTW - THIS SCRIPT REQUIRES THE VERY LATEST DEV. BUILD
-Shawn
| Description: |
| Registry Editor (Readonly) |
|
Download |
| Filename: |
reg.kix |
| Filesize: |
12.35 KB |
| Downloaded: |
800 Time(s) |
|
|
| Back to top |
|
 |
Shawn
KiXforms Developer
Joined: 22 Feb 2003
Posts: 1983
Location: Canada
|
| Posted: Sun Jan 15, 2006 1:42 am Post subject: |
|
|
| Decided to go with the System.Sender and System.EventArgs property names ... dev build and this script updated to reflect changes.
|
|
| Back to top |
|
|
Lonkero
KiXforms Devotee
Joined: 13 Mar 2003
Posts: 1022
Location: Espoo, Finland
|
| Posted: Sun Jan 15, 2006 1:36 pm Post subject: |
|
|
isn't sender a eventArg?
why separate properties?
_________________
Hammer |
|
| Back to top |
|
|
Shawn
KiXforms Developer
Joined: 22 Feb 2003
Posts: 1983
Location: Canada
|
| Posted: Sun Jan 15, 2006 3:12 pm Post subject: |
|
|
| Your right. Sender "could be" exposed through EventArgs (like you say, it is there, buried under-the-covers), let me think about more.
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
