design question - global GUI?

  • Thread starter Thread starter Norvin Laudon
  • Start date Start date
N

Norvin Laudon

Hi,

I find in the typical applications I develop in C#, I have a UI form, and a
bunch of my own classes (instances of which are used in the forms).

Almost always, these child classes need interaction with the UI. Some need
to display something to the user, and others need to get input from the
user.
Consequently, in my forms, I find myself writing tonnes of events (which can
be raised by the class to pass some info to the form), and simple
"forwarding" method calls (i.e. when someone clicks a button on the form,
the event handler for that button simply calls a method on the child class).
Lots of extra code for no observable benefit...

Does anyone ever take the approach of having the UI (or parts of it)
globally accessible by all classes? Any pitfalls to this approach? (Is it
even possible?)

Just looking for ways to cut out all the extra code...

Thanks,
Norvin
 
Have you ever used the command pattern or Model View
Controller, this removes the user interaction from the UI
 
Have you considered using a base control in which you've written all the
event, then inherit from this control. Say for example all your controls
need to raise a 'Save' event, on the base control place the methods etc. to
manage the triggering of events etc - any control inheriting from this base
can then call the method (eg base.Save())
 
Hi John,

John said:
Have you ever used the command pattern or Model View
Controller, this removes the user interaction from the UI

The command pattern, as I understand it, basically involves encapsulating
some request by the child class into a common object. (i.e. a request to
show some data, or get some user input)
The UI then interprets this request & decides what the child class wants.

In any case, this interpretation of command objects seems to be more work
than just allowing the child class direct access to the members of the UI...

But thanks for the pointer to MVC, I'll have a look at it and other design
patterns.

Thanks,
Norvin
 
Noonu,

Noonu said:
Have you considered using a base control in which you've written all the
event, then inherit from this control. Say for example all your controls
need to raise a 'Save' event, on the base control place the methods etc. to
manage the triggering of events etc - any control inheriting from this base
can then call the method (eg base.Save())

Unfortunately, my classes are typically very different from each other. None
of their events are similar enough to justify encapsulating common behaviour
into an inheritable class.

Thanks,
Norvin
 
I created a class with static members which I then could create instances
of in other forms and set/change the ifo which beign statis woudl then
pesist to other instances.

phil crosland
 
Have you tried hooking your form's events directly to the other classes -
i.e. each has eventhandlers (etc). This may be OK - but could get fairly
messy.

I use the command pattern which scales rather better than direct event
hooking or delegation.

Paul
 
Hello

I really need this also. Have you found a solution to your problem???

I also have many formm which need to have a 2 way communication and so far i
havn't found a way.

Offcourse there is this deligate and events but it don't seem like a good
way when you have so many events and

Components in the GUI :(

I wish it was more like borland. In Builder i can define a export pointer
and use it everywhere.

Anyway please let me know if you have a solution and i will also notify you
if i find a way.

I can send a pointer to the form to eachother but i don't know how to use
this. I mean i can typecast it and it works fine but

If i include the headerfiles in eachother there will be a problem so guess
this in an dead end also :(

Hope to hear from you

Thanks

/Reza
 
[This followup was posted to microsoft.public.dotnet.framework and a
copy was sent to the cited author.]

Hi,

I find in the typical applications I develop in C#, I have a UI form, and a
bunch of my own classes (instances of which are used in the forms).

Almost always, these child classes need interaction with the UI. Some need
to display something to the user, and others need to get input from the
user.
Consequently, in my forms, I find myself writing tonnes of events (which can
be raised by the class to pass some info to the form), and simple
"forwarding" method calls (i.e. when someone clicks a button on the form,
the event handler for that button simply calls a method on the child class).
Lots of extra code for no observable benefit...

Does anyone ever take the approach of having the UI (or parts of it)
globally accessible by all classes? Any pitfalls to this approach? (Is it
even possible?)

Just looking for ways to cut out all the extra code...

Thanks,
Norvin
Is it possible that I am missing something, but could each of the class
not have their own handling of the PreRender and Render event?

Is this possibly one of the problems that I have encountered in regards
to some of the methods in the classes being protected, and therefor the
main control class can't get at them except with special 'assembly
code'?
Let me know please, it this helps or not
 
Back
Top