Re: Separating code from UI

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"MP" <NoSpam@xxxxxxxxxx> wrote
with the philosophy of decoupling ui from business logic in mind,
What is the preferred way for the "remote" proc to communicate back to the
form?

The first thing I would mention is not to get too carried away with some
philosophy that it makes your design significantly more difficult. If you
have code that interacts with 'the' form you call it from, then it should
probably be in the same module as all the other code for that form.

If you have (as you possibly intended) a routine that may be called from
several different places, different forms, (whatever) then consider returning
your value(s) from a function, or raising events from a class.

When you talk about decoupling, you should be thinking 'black box'
barriers where one knows nothing about the other except through the
public interface.

While I wouldn't disagree with passing in a lable to provide updates
(or whatever) I would suggest that such a parameter creates a dependancy
which makes it not so 'decoupled' anymore....

Had you wrapped your routines in a class and provided a Cancel routine,
as well as the progress 'event', I'd say that would be moreso 'decoupled'.

FWIW, YMMV...
LFS






.

Relevant Pages

  • Re: FindReplace - Bruce said it couldnt be done...
    ... the "framework" seems to work just peachy (no crashes or the like). ... Yeah, right now, it's just raising events to alert the client what the user asked for. ... The reason I was thinking passing the original text, was that a handle would limit the types of controls you could use the dialog with. ... I suppose there could be one specialized All-In-One routine that was just for textboxes, and another that simply took the original text and told you where the "next" instance was. ...
    (microsoft.public.vb.general.discussion)
  • Re: Comparing string input to enum data type
    ... It isn't clear why you chose to #define those. ... needs to be reflected in the routine, so decoupling the symbols from ... the routine does not buy you anything obvious. ... You only use the COLORS macro in one place in the code you showed us, ...
    (comp.lang.c)