Re: mucking with Event Definitions to get tighter coupling to Objects ?



"You might do well to consider the maintenance burden and learning curve you
are creating for anyone who has no idea how your custom event model works."

I wouldn't call what I am doing a "model" right now; I am just creating some
legitimate (in the sense of they will compile and work) variations in the
typical use of the Events "standard model" and thinking, studying, what
might be the costs/benefits/gotchas of using those variations.

"As complex as your model is apparently getting throughout the day [today]
with your base classes and whatnot,"

I wouldn't call it growing in complexity. Probably I'm just making it sound
more complex than it is. Separating out Event definitions which are common
to many run-time created windows (not specific to specific windows) into a
Class of their own to me results in more readable and more maintainable
code. For me the required discipline of writing static Classes seems to make
me pay more attention to the way I code :

being static means never being born new :)

and I like the idea that something meant to be defined once and only once (a
mini-singleton ?) should be ... defined ... only once : which writing as
static forces me to do. Similarly use of Interfaces that inherit from
Interfaces judiciously to me is a small task compared to the benefits of
knowing immediately (because they won't compile if they don't) that my
Classes that inherit from those Interfaces comply with the Interface
contract (casting to Interfaces, another story ... for me, so far).

"you are also creating a solution-specific implementation of your event
model. At least that's the case unless you refactor it out into some plug-in
architecture or such whereby you have a library that you can drop into any
project and your custom event stuff is all ready to "just use.""

I would disagree with you there. I can see what I am doing now as
establishing a basic MVC application template I will use from now on in any
WinForms project I do where multiple secondary windows Forms (Parent ==
null) are created at run-time, based on an end-user's selection of what
pre-defined Window Template to use. And those are the kinds of projects I
do. Within that larger meta-project (based on my unhappiness with the
"standard models" of SDI and MDI window management) this excursion into
Event handling has an organic role.

Long before I ever heard about MVC, maybe the late 1980's (? ... yeah, I'm
that antiquated :), I was talking about "one data many views," and that's
been a "Grail Quest" for me ever since.

"Maybe I'm wrong, but based on what you are writing, it seems to be getting
less and less like an academic exercise whereby you are gaining some
"appreciation" for the standard way to do things."

My honest assessment is I yet don't know the outcome of this "thought
experiment." For me doing these kinds of things pay off, most of the time.

"Maybe I'm missing something. Have you gained any new appreciation for the
"object sender
EventArgs e" standard? Or do you like it less and less as you evolve your
ideas. Maybe you could share with us, briefly, what you have concluded to be
the important trade-offs between the standard and your own model."

I'd distinguish between endorsing the concept of event multi-casting
fervently, and mixed feelings about the sender-e syntax of the
implementation of that paradigm. That may change.

If I reach the point I have something which I feel other developers can
benefit from, certainly I'll publish ! This is about sharing, to me.

I do appreciate your comments, they seem constructively challenging to me.

best, Bill

.



Relevant Pages

  • Re: Microsoft Says Recovery from Malware Becoming Impossible
    ... a Microsoft security official said ... dollar everytime I caught something on Windows I could retire very ... what became an industy standard ??? ... And who actually invented XML??? ...
    (microsoft.public.security)
  • Re: What if Microsoft never existed?
    ... MS Word 1.0 for Windows was way ... >>> Without the standard, the life of developers would be hell. ... >>>is dead (OK, they still do releases, but largely based on Mozilla), ... But when Word will create/edit .pdf, ...
    (comp.sys.ibm.pc.hardware.chips)
  • Re: Good Lisp editor for Win
    ... Emacs went away from those and in the process was awkward. ... Windows was create in 1983 ... windows decides what is standard and what's not. ... surrendering the truth just because it is ...
    (comp.lang.lisp)
  • Re: OT: Win 7 comments
    ... see nothing in it that the standard Win32 menu control doesn't do. ... If you just blame the registry rather than troubleshooting, you can't fix it, and you have to rebuild. ... And on Windows, deleting preferences is not a time-hallowed ritual for exorcising demons from the computer. ...
    (comp.sys.mac.advocacy)
  • Re: Graduate Teacher Programme - best way to approach it
    ... It is a de facto standard. ... aiming to teach transferable skills- so pupils can adapt to use applications ... Linux just happens to be the only viable competitor to Windows ...
    (uk.education.teachers)

Loading