Resolve Sender ambiguity

agraham

agraham

Expert
Licensed User
Longtime User
Am I missing something? It seems that Sender only returns the last part of a controls name e.g. "Button1". As I can have a Button1 on different Forms in different modules but wired to a common Click event I don't seem to be able to identify which "Button1" of which module actually raised the event! Sender does know this and gets/sets properties on the correct button but I cannot see the full name in my program.

I know that I can overcome this by giving each button a unique name but that seems to undermine the use of modules for segregation.

Perhaps we could do with a SenderFullName keyword or something similar to get the fully qualified name of the Sender of an event.
 
agraham said:
Perhaps we could do with a SenderFullName keyword or something similar to get the fully qualified name of the Sender of an event.
Click to expand...

MY PREFERENCE WOULD GO TO A SENDER.PARENT PROPERTY, AS IT WOULD ALLOW ITS USE IN OTHER SCENARIOS....
THUS WE COULD GET THE FULL CONTROL NAME BY HAVING:
SENDER.PARENT & "." & SENDER

EDIT:
JUST MISSED EREL'S POST....
STILL I MAINTAIN THAT A PARENT OR MODULE PROPERTY FOR THE CONTROLS WOULD BE BEST AS WE COULD GET ONLY THE MODULE NAME INSTEAD OF HAVING TO TRIM THE FULLNAME JUST TO GET THE MODULE...
 
Last edited:
Erel said:
A new property will be added to all controls: FullName, which will include the module name.
Click to expand...
I haven't fully thought this through (and can't at the moment as I am being dragged out by "herself" to a craft fair) but what about events from similarly named library objects owned by different modules?
 
@Cableguy, I prefer to return the full name because in most cases that is the required value.
Like in: Control(Sender.FullName).SomeProperty.

@agraham, that's a good point. I will think about it a little more, but maybe instead of adding this property I will a new keyword SenderFullName, which will behave exactly as Sender but will return the full name (object or control).
Sender will continue to return only the control's "short" name to avoid backwards compatibility issues.
 
Just to chime in here - I can't say for sure what the best solution is, but with respect to the 'parent' idea - there have been times-a-plenty when I've really, really wanted the ability to resolve the parent of a control.

Before I get scolded, yes, I know this can be done with some recursive GetControls() thing. It works. I'd just love to have Button1.Parent available, or GetParent( "Button1"), or something like that.

If this could be implemented at the same time as the full name, why, you'd make me the happiest mobile programmer in the world... *sniff*

Gary
 
willisgt said:
you'd make me the happiest mobile programmer in the world... *sniff*
Click to expand...
Your wish is my ...

Using the Door library and a bit of inside knowledge. Note that the name is subtly different in an optimised compiled app. It is pre-pended with a single underscore interpreted and two underscores optimised compiled. This won't work on a FormExDesktop.
 

Attachments

You must log in or register to reply here.
Back
Top