Re: Advice Sought

On Wed, 19 Jul 2006 11:14:13 +0100, "Steve" <someone@xxxxxxxxxxxxx>
wrote:

Hello All

Please forgive the vagueness of this post, but it's really to get some ideas
on what's the best way to address a particular problem which is looming on
the horizon.

<snip>

Very interesting

Basically you want a number of co-operating Apps that appear to just
be one App.

A sensible solution, much safer for development as it will force rigid
channels of communication.

You can 're-parent' EXEs using Windows.SetParent
- embedding other Apps in one Host App is quite easy

Alternatively you could create each 'App' as a stand-alone DLL and
pull it up using LoadLibrary.

I've just spent quite a bit of time looking at re-parenting Forms in
DLLs onto a host Form
- re-parenting to a bland HWND is not that satisfactory, but
re-parenting to a Control works with a few problems concerning the
startup position.

It is a bit dubious passing a Control to a DLL, since it assumes that
both Objects are identical in different memory locations.
It looks as if looking into BPLs might be an idea - for the core
library, not necessarily anything else.

For the message passing schema I would use something a bit like the
dreaded DDE
- partly because I've made things that communicate very nicely between
EXEs using a boxed up version of WM_COPYDATA

- and partly because it is sufficiently restrictive to ensure
relatively water tight bulkheads - things can only broadcast and
receive (in my version) so they know squat about anything else.

Whether you use DLLs or EXEs is moderately irrelevant, the Host form
will know very little about what is inside it, ideally little more
than the contents of a simple INI file.

There will be a little ugliness with the Host Form losing focus, but
that should be pretty easy to fix - just use the API to draw the title
bar.

Long before I came to Windows, I decided that cutting Apps down into
numerous repetitive EXEs was by far the easiest solution for rapid
development and building watertight 'components'.

What an App doesn't know about, it can't muck up, which is very
reassuring if one is shipping code fast.

I reckon that you have a viable design, provided you keep it simple
and avoid any flashy 'bleeding edge' technology, you could have a
robust framework that looks very acceptable to Users, yet is
internally very simple.

I suggest that you put aside a day to experiment with re-parenting
Forms in DLLs (using LoadLibrary) or EXEs


.

Relevant Pages

  • Re: Advice Sought
    ... be one App. ... I certainly hadn't come across re-parenting, but it's an area I will ... You can 're-parent' EXEs using Windows.SetParent ... DLLs onto a host Form ...
    (alt.comp.lang.borland-delphi)
  • Re: How to share the same configuration files between several assemblies (executbles)?
    ... you mean many DLLs in your app, you already have one config file. ... best way I've found is to have all of the config files of the different EXEs ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: private Deploy of SQL CE 3.1
    ... my app is always a newer one than whatever is in ROM, ... device uses 3.1 dlls. ... All was fine as long as my desktop app was ... I also found that in Platform builder when I removed "sql mobile" ...
    (microsoft.public.sqlserver.ce)
  • Re: private Deploy of SQL CE 3.1
    ... my app is always a newer one than whatever is in ROM, ... device uses 3.1 dlls. ... All was fine as long as my desktop app was ... I also found that in Platform builder when I removed "sql mobile" ...
    (microsoft.public.sqlserver.ce)
  • Re: private Deploy of SQL CE 3.1
    ... my app is always a newer one than whatever is in ROM, ... device uses 3.1 dlls. ... All was fine as long as my desktop app was ... I privately deploy my SqlCe DLLs with my apps, ...
    (microsoft.public.sqlserver.ce)