Check if a Public Method exists for a form and execute it
Jeff
google.
1. Have a method from the main app to get all open forms
2. Check each open form for a public method
3. If this public method exists execute it which will result in the
displayed form being updated. There will be no data loss as the forms
will only contain listviews or readonly fields.
Regards
Jeff
Peter Duniho
wrote:
I don't really understand the last statement, as neither the question of
ListView instances or of readonly fields affects whether there could
potentially be data loss.
However, to address your specific question, you are looking for the
Reflection namespace. You can use GetType() on each form instance to get
its actual type, and then use that Type instance to look for particular
members, including a method to invoke.
That said, using Reflection should be a last resort. As an example here,
it would be much better if each form that might need this method to be
called instead implemented the method as an event handler. Then the
application would define an event each form could subscribe to. When the
event was raised, each form would then have its method executed
automatically, without having to go through all the reflection rigamarole.
If for some reason that and any other potential alternative isn't
possible, then reflection is your answer.
Pete
Jeff
Something new for me to learn and try.
This opens up something I did not know you could do and it seams that
events can be across applications and one application can fire an even
in another if they are both subscribed.
Now to find a good article and sample code.
Jeff
Peter Duniho
wrote:
> This opens up something I did not know you could do and it seams that
> events can be across applications and one application can fire an even
> in another if they are both subscribed.
Well, when I wrote "event" I was speaking of the .NET/C# variety of
events. The unmanaged Windows API also has the concept of "events", but
they aren't subscription based, and while named events can be
cross-application (i.e. cross-process), they are only useful for
communicating a toggle state.
There was nothing in your original question that suggested you needed a
cross-process solution. If you do, then neither reflection nor a C# event
will help.
If you don't need a cross-process solution, then you may want to start
here:
http://msdn.microsoft.com/en-us/library/8627sbea.aspx [event (C#
Reference)]
Be sure to visit this page too:
http://msdn.microsoft.com/en-us/library/awbftdfh.aspx [Events (C#
Programming Guide)]
It contains lots of links to additional useful articles on the topic.
Pete
Nathan
be the easiest solution. Require all your forms to implement an interface
with that method defined; then you can loop through all the forms and call
that method on each.
"Jeff" <jeff@[_nospam_].hardsoft.com.au> wrote in message
news:tN2dnUuKAM0_gLjV...@posted.internode...
Family Tree Mike
2. Checking for a method could use reflection, but if this is code
internally developed by you, you should be able to cast to the appropriate
form type and know that the method exists.
3. (i wouldn't separate 2 and 3.)
Peter Duniho
<mspas...@macgregorfamily.net> wrote:
> Maybe I'm misunderstanding you, but it sounds like using an interface
> would be the easiest solution. Require all your forms to implement an
> interface with that method defined; then you can loop through all the
> forms and call that method on each.
This is a fine approach as far as it goes. It's certainly a lot closer to
what the OP specifically asked for, and assuming he has the ability to
modify the form classes, is much better than using reflection.
That said, it's a bit "Java-like", especially with respect to defining an
interface with only one method just so you can call that one method. Not
that there's anything technially wrong with being "Java-like" :). Just
that in .NET, with delegates and events, it's more common to approach this
sort of problem using events.
Even .NET has a handful of interfaces that have just one method. It's not
that it's necessarily bad design to do so. But for me, interfaces are
more about abstraction than about conditional processing. With the "is"
or "as" operator, an interface implementation would definitely work fine,
but if one is going to have to change the original class anyway, an event
is IMHO more in line with the usual .NET paradigms than defining an
interface that has only one method. It also avoids the need to enumerate
all of the open forms, instead taking advantage of the multicast nature of
an event to directly retrieve the group of form instances that is exactly
those that will response to the specific operation.
That said, I think that which is preferable may really come down to what
this operation actually is. Since we don't have that detail, only the OP
can determine the answer to that. If it's a case of an operation that is
best thought of as "these forms implement a certain kind of behavior that
needs to be used at some point in time", then I think the interface
approach lends itself very nicely to that. On the other hand, if it's a
case of an operation that is best thought of as "this particular thing
happens at a particular point in time and these forms need to be informed
about that", then an event is probably paradigmatically more appropriate.
Pete
Chris Shepherd
This last part is interesting. Are all these forms using a common data source?
If not, could they be?
It reads like you've got the same data in several places, and it would make more
sense to have a datasource that itself gets updated, and then the forms can
handle dealing with the updated datasource on their own.
Chris.