Re: How Big is Too Big?

Tech-Archive recommends: Speed Up your PC by fixing your registry


"Michael C" <nospam@xxxxxxxxxx> schrieb im Newsbeitrag
news:efcpQY3EHHA.2176@xxxxxxxxxxxxxxxxxxxxxxx
"Schmidt" <sss@xxxxxxxxx> wrote in message
news:O7ZQWI3EHHA.996@xxxxxxxxxxxxxxxxxxxxxxx

[TypeOf, LateBinding and Common-Interfaces]
Clearly you don't know what an interface is.
If you say so...
Describe for me an interface then.
No, first you should describe for me, what do you think
IDispatch (and IUnknown) are.

No, working with them is the same. :-)
AGAIN, it is similar but NOT the same...
Again, working with them is the same.
...Are you dense?
No, I'm only *patient*. :-)

If you don't believe me, then look into the MSDN.
Jim already has posted a link, where is stated, that using the
common Form-interface means LateBinding.
No, Jim stated it *can* be late bound. There is a big difference
that you clearly don't get.
I hope you remember, where the topic was coming from.
You was asking, how to access the Forms-Collection of the
MainApp (probably to get the information, if a GUI-Module
already is loaded, to get a reference to it and use its functionality
from other components if so - or to instanciate a new GUI-
Module if not).
In a "NonComponentized", "normal" App you would write:
Dim Frm as Form
For Each Frm in Forms
If TypeOf Frm Is TheNeededType Then
ReturnWithThisReference 'so you can cast and use it
Exit Function
End If
Next Frm
ReturnWithNothing 'signalize, that you have to create a new instance

I was replying, that in a dynamic, OCX-based scenario the
same task could look like this:
Dim Frm as Form
For Each Frm In Parent.FormsCollection
If TypeOf Frm.DynOcx Is TheNeededType Then
ReturnWithThisReference 'so you can cast and use it
Exit Function
End If
Next Frm
ReturnWithNothing 'signalize, that you have to create a new instance

That solves perfectly your problem of getting a reference from
inside B1 to use (E-Mail-)functionality in an (possibly) already
running B8.
That's why I've told you, that I already answered your question(s).
But the GUI-components in B1 to B8 have to be implemented
as OCX's then and not as "Dll-Forms". And that recommendation
was made (even by others in this thread) before too.

Anyway; you replied to the above:
"All looks pretty messy to me. Lots of late binding."
Hmm, first *you* should decide, what holds true now.
Is it LateBinding for you or not.
For me it is, yes.
But after returning from this Forms-Loop you can
cast to your concrete FormType (or OCX-Type).

It *is* simple, but probably you'll be overstrained with this task.
You want it to be simple so you can post a simple reply.
If you want, you can make the example as "complex" as you can.
I would in either case show you the dynamic pendant.
But as I told you before, that is not needed, because the few
differences to a "normal" Application can be addressed in a
very basic example.

Yep, as I told you before. You will have to split your business-
logic too into separate Components C1, C2, etc., to avoid
problems using the approach - ergo the approach forces you
to split, wich leads to a better overall-design.
So now we have 10 guid dlls and 10 business logic dlls and 10
database dlls...
You don't get it.
You have to design your business-logic in a way, that you can
reuse the code in your GUI-components without Code-
Duplication.
That does *not* mean, that every GUI-Component B1 to Bn
needs appropriate pendants C1 to Cn.
If you do it right, then e.g.:
B1 to B3 use only C1
B4 to B6 use C1 and C2
B5 uses only C3
B6 to B8 use C2 and C3

(In my thinking, the direction is the opposite, more BL-centric:
C1 uses B1 to B6
...
C3 uses B5 to B8
But if i'd come up with this now, then you'd probably be totally
confused)

But C and D both have many many classes that are shared
and duplicated. This is very messy.
If it is messy, then your design of C and D is wrong.
You should get a good book about this topic.
If you do it right, then there's no problem, to split your
Business-Layer C into more than one Dll.
If e.g. C3 itself needs something from the already finsihed C1 -
where is the problem, to reference C1 inside C3 and
use the C1-functionality over a stable interface.

I subclass in my application.
Whoaa. ;-)

If the usercontrol needs to subclass the form it will need to obtain
hWnd etc. This *is* part of the problem ...
If you need the hWnd of the GUI-Component, then use
UserControl.Hwnd inside the OCX - if you need the hWnd
of the generic HostForm, then use UserControl.ContainerHwnd.
No clue, what your problem is.

Currently you are in a position, where you can say:
"Ok, my app needs 50 seconds to start, but it is very well
designed, because I've placed all my Business-Logic in only
one Dll and avoided LateBinding completely."
Sounds somewhat alien, right?
So where do you wanna go today? <g>
I think the real problem with the slow startup time is that too
much code is in the GUI layer.
Yep - and in a really bad way "crossreferenced", that you
cannot split it up with ease into separate Components.
Well designed GUI components shouldn't need to know
much about each other.

Business logic code wasn't farmed out to appropriate dlls
well enough.
Yep. Functional Splitting of your BusinessLogic is needed and
not a dumb B1-C1, B2-C2, ..., Bn-Cn approach.

Although the *real* root of the problem is that VB6 is not
*scalable*.
I would say, the real root of the problem is, that your mind seems
not very scalable. ;-)
SCNR

Olaf


.