KiXforms Forum Index KiXforms
The Forum for the KiXforms Community
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
 Quick Links 
Site News
Downloads
Documentation
Donations
Script Archive
Tracking Systems

Request for comment - TreeView OnBeforeExpand Eventing

 
Post new topic   Reply to topic    KiXforms Forum Index -> Discussion
View previous topic :: View next topic  
Author Message
Shawn
KiXforms Developer
KiXforms Developer


Joined: 22 Feb 2003
Posts: 1983
Location: Canada

PostPosted: Wed May 19, 2004 7:59 pm    Post subject: Request for comment - TreeView OnBeforeExpand Eventing Reply with quote

Request for comment:

I'm looking at trapping the OnBeforeExpand event in TreeViews (a very usefull thing to be able to do) and this would apply to context menus as well, when you right click on a TreeView node ...

There is the concept of the "SelectedNode" in the TreeView and another thing just called the "current node" (my term) ... one can have a node selected (call it NodeA) yet right click or expand another node (NodeB) without selecting it ... therefore when an event occurs, the SelectedNode property is kinda useless to retrieve which node the user is working with ...

In dotnet, this "current node" is usually passed to the event function in the form of an EventArg, looks something like:

Function OnBeforeExpand($TreeView, $EventArgs)

where $EventArgs is an object that contains properties related to the event your processing ... so in this case the current node would be teased out of this object like this:

$CurrentNode = $EventArgs.Node

actually for some reason (?) the common name of the eventargs arg is just simply $e like this:

Function OnBeforeExpand($TreeView, $e)

anyways, since in Kixforms can't directly call a Kixtart function under the covers, have to "expose" this EventArgs object somewhere else ... so was thinking about at the root $System level ... therefore whenever an event is called, the script can query the value of $System.EventArgs to get the details relating to the event that just occurred ... this was the tact I was going to take ... so it would look like this:

$TreeView.OnBeforeExpand = "OnBeforeExpand()"

;...

Function OnBeforeExpand()

$node = $System.EventArgs.Node

?"Text = " $node.Text

EndFunction

There are actually probably numerous other ways this could be implemented, say by having a new property in the TreeView that represented the "current node", and maybe some other ways too ... there may be other ways to implement the EventArgs object itself ... thing with System.EventArgs is ... it can be used by ALL objects - not just the TreeView ... in dotnet, EventArgs are used for mouse movement coords, keyboard input information - all kinds of things ...

In regards to the OnBeforeExpand event - we discussed the way it would work in that if you trapped the OnBeforeExpand through events, then the Expand itself would actually be canceled (or overriden) by Kixforms, and then it would be up to the script to "finish" the expand ... but there was that race condition problem we wanted to avoid ...

Propose to solve this by having an extra parameter to the Expand method (which aint in the current build) that allows you to expand a node the regular way (and get the associated before and after events sent back to you) and to expand a node and purges the events (when like your completing the expand in the OnBeforeExpand event) so would be like:

$Node.Expand() ; with events

$Node.Expand(0) ; no events

Thoughts anyone ? Aspirin ?
Back to top
View user's profile Send private message
Stevie
KiXforms Supporter
KiXforms Supporter


Joined: 04 Jun 2003
Posts: 109

PostPosted: Thu May 20, 2004 12:34 pm    Post subject: Reply with quote

$System.EventArgs is a great idea. Having a global placeholder for eventargs will be easy to use and easy to remember. As you begin populating different events with event args, the trickiest part will be knowing what objects are available under the EventArgs object for each event type that includes eventargs.

The only problem I see with that down the road is that if kixforms ever supports multi-threaded operations, then the global eventargs implementation could become problematic--nothing to worry about for at least a few more weeks, right? Smile

As to the expand discussion, I'm a little lost there.
Quote:
$Node.Expand() ; with events
$Node.Expand(0) ; no events

Let me try to restate what you're saying so you can figure out if I got it or not:
$Node.Expand(0) is to be used inside OnBeforeExpand so that no events are trapped, because presumably they would have already been trapped earlier in code execution. That part I think I got.

Where I get lost is $Node.Expand(). By my reckoning, this one would rarely, if ever, get called since the expansion of nodes would be user driven if they click the plus sign, or double-click a node, etc. So either you're including it for completeness so that nodes can be programmatically expanded, or you're implying that we need to call expand in response to a user double-clicking a node--in essence, handling node expansion exclusively through the script and not through kixforms.

Either way I understand the purpose behind the Expand(0) and think that the solution is a good one. Just one thought...

Instead of overloading the Expand argument to accept nothing or an int, how about Expand([disable events as int = 0]), so that you now have:
$Node.Expand(0) ; with events
$Node.Expand(1) ; no events

And accepting a default value of 0 if no value is supplied. This might make it easier down the road with other method calls that accept params if they're not overloaded, but are optional with default values. Not so much in this case, but in other cases having a consistent set of args would make it easier to build Execute strings using code logic. Not really an important issue either way but thought I'd throw it out nonetheless.
________
Motorcycle tires


Last edited by Stevie on Fri Feb 18, 2011 8:53 am; edited 1 time in total
Back to top
View user's profile Send private message
Bonji
KiXforms Aficionado
KiXforms Aficionado


Joined: 10 Mar 2003
Posts: 393
Location: Virginia

PostPosted: Thu May 20, 2004 12:34 pm    Post subject: Reply with quote

After reading this a few times I believe I have the jist of it. Being able to work with the "current node" definately sounds like something we would like to be able to do, and your method for doing that sounds very acceptable to me.

As far as OnBeforeExand, I like the sounds of specifying a parameter to change the behavior to give the most flexibilty without making it too hard to work with when you don't need that flexibility.

I'm a YES man!

Seriously, it all sounds good to me.

_________________
-Ben
Back to top
View user's profile Send private message
Lonkero
KiXforms Devotee
KiXforms Devotee


Joined: 13 Mar 2003
Posts: 1022
Location: Espoo, Finland

PostPosted: Thu May 20, 2004 4:40 pm    Post subject: Reply with quote

onbeforeexpand?
hmm... don't see any usage for that in any way.

_________________
Hammer
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Stevie
KiXforms Supporter
KiXforms Supporter


Joined: 04 Jun 2003
Posts: 109

PostPosted: Thu May 20, 2004 6:54 pm    Post subject: Reply with quote

Anytime you want to do an "on demand" population of treeview child nodes. For example, let's say you want to make an explorer control in KiXforms. When someone opens the C: drive and exposes all the folders under c:, that is not the time you want to populate all of those nodes' children.

You only want to get all the subfolders under it when someone actually expands it. Otherwise, you'd be populating a bunch of data for items that will never be expanded. So you'd check to see if each given node has any subfolders/files, and if so, add a dummy child node so that the plus sign will appear.

When the user expands a child node, that's when you use OnBeforeExpand to see if the dummy child node is there, and if so, populate the children with real data.

There's a lot of instances where you want to do child node population on an "on demand" basis.
________
Justin bieber


Last edited by Stevie on Fri Feb 18, 2011 8:53 am; edited 1 time in total
Back to top
View user's profile Send private message
Shawn
KiXforms Developer
KiXforms Developer


Joined: 22 Feb 2003
Posts: 1983
Location: Canada

PostPosted: Thu May 20, 2004 11:49 pm    Post subject: Reply with quote

I love RFC's ...

First thing re: multi-threading ... when I thought up this eventargs scheme thats the first thing that crossed my mind ... all kidding aside, I highly doubt that a multi-threaded feature could ever be added into Kixforms - would require a major reworking of KF at the very least (like if one wanted to call KF from a compiled language)

Im including both versions of the expand for completness ... a script may want to expand the first node of a tree for the user, or more likely, expand the last node the user was working with on the user's behalf (kinda like the way regedit works under NT5 works) ...

One of the ways I could work things is to have to a single version of expand that never generates any events ... regardless of whether its called from an event or not ... this warrants consideration i think ... after all, if your expanding a node in script - then does one really need to have the events sent back to you ... one can just pre-populate the node ahead of time anyways because you know its going to be expanded !

Any thoughts on this ?

But if we do need a flag in Expand() then I will implement it like you suggest, makes sense to me ...
Back to top
View user's profile Send private message
Stevie
KiXforms Supporter
KiXforms Supporter


Joined: 04 Jun 2003
Posts: 109

PostPosted: Fri May 21, 2004 1:54 pm    Post subject: Reply with quote

Quote:
One of the ways I could work things is to have to a single version of expand that never generates any events

I don't see how this is different than your original idea. Wasn't the Expand() with and without arguments determining if events would be generated for the expand operation?
________
Halfbaked


Last edited by Stevie on Thu Mar 17, 2011 9:18 am; edited 1 time in total
Back to top
View user's profile Send private message
Shawn
KiXforms Developer
KiXforms Developer


Joined: 22 Feb 2003
Posts: 1983
Location: Canada

PostPosted: Fri May 21, 2004 2:18 pm    Post subject: Reply with quote

Yeah, what i was thinking about was having an expand method with no arguments at all, and just state that a scripted expands will never generate events - user initiated expands will always generate events.

Because scripted expands never generate events, one can use them anywhere in the script (in the OnBeforeExpand event to complete the expand, or anywhere else) ... I'm just trying to think whether not having the event sent back to you is major deal or not (when using scripted expands)

edit - Guess having the flag is just extra gravy though ... just trying to make this as intuitive as possible.
Back to top
View user's profile Send private message
Stevie
KiXforms Supporter
KiXforms Supporter


Joined: 04 Jun 2003
Posts: 109

PostPosted: Fri May 21, 2004 6:55 pm    Post subject: Reply with quote

If you can't think of any situation (and I can't) where you would script a node expansion and still want to get events for it, then the scripted expand that never uses event is probably easiest for everyone.

Well how about making no events the default? Expand([int as DisableEvents = 1]). Then if you want the events, you have to explicitly call Expand(0), otherwise just leave it empty.
________
TEEN VIDS


Last edited by Stevie on Fri Feb 18, 2011 8:53 am; edited 1 time in total
Back to top
View user's profile Send private message
Shawn
KiXforms Developer
KiXforms Developer


Joined: 22 Feb 2003
Posts: 1983
Location: Canada

PostPosted: Fri May 21, 2004 9:05 pm    Post subject: Reply with quote

Think what I will do in the short-term is have a simple Expand() that doesn't cause events ... see how things go - can always add the eventing later if it becomes an issue.
Back to top
View user's profile Send private message
Lonkero
KiXforms Devotee
KiXforms Devotee


Joined: 13 Mar 2003
Posts: 1022
Location: Espoo, Finland

PostPosted: Fri May 21, 2004 9:55 pm    Post subject: Reply with quote

so...
if you populate with onbeforeexpand, where you would use onexpand then?

_________________
Hammer
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Stevie
KiXforms Supporter
KiXforms Supporter


Joined: 04 Jun 2003
Posts: 109

PostPosted: Fri May 21, 2004 11:46 pm    Post subject: Reply with quote

That's a good question. I'm sure it gets used a lot by people, but I don't think I've ever used an OnExpand event for a treeview. I've never needed to be notified after they've expanded a node.

If you're pre-populating nodes one level deep, then maybe it would be useful. Like if in the Explorer example when someone opens the C: drive folder you populate all of the grandchildren of the c: node so that when they click on the child of c:, the nodes are already there, but then you'd have to populate those grandchildren, etc.

Don't think it's a good design pattern, but I don't know when else you might use it.
________
Medical Marijuana


Last edited by Stevie on Fri Feb 18, 2011 8:54 am; edited 1 time in total
Back to top
View user's profile Send private message
Stevie
KiXforms Supporter
KiXforms Supporter


Joined: 04 Jun 2003
Posts: 109

PostPosted: Fri May 21, 2004 11:47 pm    Post subject: Reply with quote

And I think that's a good idea, Shawn. I agree--there won't be much use for the event-driven expand anyway.
________
Honda ha-420 hondajet specifications


Last edited by Stevie on Fri Feb 18, 2011 8:54 am; edited 1 time in total
Back to top
View user's profile Send private message
Lonkero
KiXforms Devotee
KiXforms Devotee


Joined: 13 Mar 2003
Posts: 1022
Location: Espoo, Finland

PostPosted: Fri May 21, 2004 11:59 pm    Post subject: Reply with quote

well, so the difference is not in the speach but in the meaning of the event.
onexpand sounds in my ear that it triggers when user clicks the expandable object so it will expand.
so, it will not be after the expand but at the same time.

if you take windows explorer and browse network folder which has lots of items, maybe even over a slow link, it gives you hour-glass.
now, that does not sound onbeforeexpand but onexpand.
it populates when expand occurs, not before it.

_________________
Hammer
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Lonkero
KiXforms Devotee
KiXforms Devotee


Joined: 13 Mar 2003
Posts: 1022
Location: Espoo, Finland

PostPosted: Sat May 22, 2004 9:36 pm    Post subject: Reply with quote

k, like I quessed, it's the naming that got me confused.
in platform SDK treeview has the 2 corresponding events named:
Quote:

TVN_ITEMEXPANDED Signals that a parent item's list of child items was expanded or collapsed.
TVN_ITEMEXPANDING Signals that a parent item's list of child items is about to be expanded or collapsed.


as far as I understood it.
like you see, the naming is totally different.
it's not onBEFORE, it's onDOINGtheExpand

_________________
Hammer
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Display posts from previous:   
Post new topic   Reply to topic    KiXforms Forum Index -> Discussion All times are GMT
Page 1 of 1

 
Jump to:  
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