Home > Archive > Visual Basic > July 2006 > VB6 - Firing DLL-based forms as MDIChild?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
VB6 - Firing DLL-based forms as MDIChild?
|
|
| MyndPhlyp 2006-06-30, 6:56 pm |
| What's the trick to getting forms compiled into a DLL to act as an MDIChild?
I'm firing the DLL from an MDI Form. The DLL's form is marked MDIChild =
True. But when the DLL is launched and the form is Show'd (whether vbModal
or vbModeless) I get a runtime error "No MDI Form available to load."
WTF? (What's the formula?)
| |
| Bob Butler 2006-06-30, 6:56 pm |
| "MyndPhlyp" <nobody@homeright.now> wrote in message
news:OYwwMpInGHA.4856@TK2MSFTNGP05.phx.gbl
> What's the trick to getting forms compiled into a DLL to act as an
> MDIChild?
There are lots of tricks that may get you close but it'll never work quite
right. The best approach IMO is to create OCXs instead of DLLs. You can
then create a new MDI child form in the parent app and use Controls.Add to
load an instance of the OCX and size it to fit the child.
--
Reply to the group so all can participate
VB.Net: "Fool me once..."
| |
| Karl E. Peterson 2006-06-30, 6:56 pm |
| MyndPhlyp wrote:
> What's the trick to getting forms compiled into a DLL to act as an
> MDIChild?
No trick at all. Literally. Can't do that.
> I'm firing the DLL from an MDI Form. The DLL's form is marked
> MDIChild = True. But when the DLL is launched and the form is Show'd
> (whether vbModal or vbModeless) I get a runtime error "No MDI Form
> available to load."
>
> WTF? (What's the formula?)
Heh, the most common workaround is to create the "form" as a UserControl,
then either embed or create that at runtime on an actual MDIChild form.
--
Working without a .NET?
http://classicvb.org/
| |
| MyndPhlyp 2006-06-30, 6:56 pm |
|
"Karl E. Peterson" <karl@mvps.org> wrote in message
news:%233eJ$tInGHA.2432@TK2MSFTNGP03.phx.gbl...
> MyndPhlyp wrote:
>
> No trick at all. Literally. Can't do that.
Thanks Karl, and Bob, for dashing my hopes. The day was pretty much a waste
to begin with. At least now I can look forward to slashing my wrists. (The
caretaker has left the asylum for the w end!)
Okay, how 'bout a different track...
This puppy is going to get far too big as a single EXE. It will definitely
have to be broken into DLLs. What gets shoveled into the DLLs is totally
dealer's choice.
I don't foresee a problem with making the MDI EXE hold all the MDIChild
forms and UCs necessary although the library is going to get a bit
congested. (And yes, I am remembering the warning about 32K worth of exposed
properties/events/methods with VB eating roughly 30K of them right off the
bat.) I suspect even with the plethora of Form objects is just ain't gonna
get all that large especially considering the design idea is to keep the
I/O, validation, and manipulating routines out of the hands of the form
developer. The UCs will have the smarts to know where to call for the data
actions and they, and the forms, will have feedback to act upon but the real
brains are removed and that is where the bear's share of code resides.
As long as I keep the display objects out of the DLLs - forms, text boxes,
lists, toolbars, etc. - this should work, right? All the MDIChild forms are
safe at home with the MDIForm. (I'm really trying to avoid OCXs. I'll resort
to API calls if I have to.)
The bonus follow-up question is what kind of limitations am I going to run
into regarding amounts of data I can pass back from a DLL call?
One example scenario is a choice list that could contain thousands of rows
consisting of a key value and a description (up to 40 characters) for each
key. Keeping this all under one roof (the all-in-one design) I could return
a Recordset from the Class and let the grid routine (ListView, actually)
pull out the data and load the object. It is keeping with the original
design concept; the dialog box has no idea what the source was for the
Recordset, only that it contains what it needs. Is this going to be possible
with a DLL? Or am I going to have to think much smaller and return each row
one at a time?
| |
| MyndPhlyp 2006-06-30, 6:56 pm |
| Thanks Bob. See the reply to Karl (below ... or above, depending on how you
sort your messages).
| |
| Karl E. Peterson 2006-06-30, 6:56 pm |
| MyndPhlyp wrote:
> As long as I keep the display objects out of the DLLs - forms, text
> boxes, lists, toolbars, etc. - this should work, right? All the
> MDIChild forms are safe at home with the MDIForm. (I'm really trying
> to avoid OCXs. I'll resort to API calls if I have to.)
I don't understand that. OCXs are just DLLs in drag. In fact, in VB6, a
DLL can expose UserControls just like an OCX can!
> The bonus follow-up question is what kind of limitations am I going
> to run into regarding amounts of data I can pass back from a DLL call?
>
> One example scenario is a choice list that could contain thousands of
> rows consisting of a key value and a description (up to 40
> characters) for each key. Keeping this all under one roof (the
> all-in-one design) I could return a Recordset from the Class and let
> the grid routine (ListView, actually) pull out the data and load the
> object. It is keeping with the original design concept; the dialog
> box has no idea what the source was for the Recordset, only that it
> contains what it needs. Is this going to be possible with a DLL? Or
> am I going to have to think much smaller and return each row one at a
> time?
It *sounds* possible, but I'll quickly say that I've never had a very
similar scenario.
--
Working without a .NET?
http://classicvb.org/
| |
| Bob Butler 2006-07-01, 7:55 am |
| "MyndPhlyp" <nobody@homeright.now> wrote in message
news:AXipg.745$ye3.526@newsread1.news.pas.earthlink.net
> "Karl E. Peterson" <karl@mvps.org> wrote in message
> news:%233eJ$tInGHA.2432@TK2MSFTNGP03.phx.gbl...
<cut>[color=darkred]
> This puppy is going to get far too big as a single EXE. It will
> definitely have to be broken into DLLs. What gets shoveled into the
> DLLs is totally dealer's choice.
An OCX *is* a DLL, just one with some bonus features
<cut>
> As long as I keep the display objects out of the DLLs - forms, text
> boxes, lists, toolbars, etc. - this should work, right? All the
> MDIChild forms are safe at home with the MDIForm. (I'm really trying
> to avoid OCXs. I'll resort to API calls if I have to.)
As I always heard growing up, you're cutting off your nose to spite your
face
You're eliminating the tool that you need to do the job for no apparent
reason.
> The bonus follow-up question is what kind of limitations am I going
> to run into regarding amounts of data I can pass back from a DLL call?
None that I know of. You can return recordsets, arrays, collections,
whatever.
--
Reply to the group so all can participate
VB.Net: "Fool me once..."
| |
| MyndPhlyp 2006-07-01, 6:55 pm |
|
"Bob Butler" <tiredofit@nospam.ever> wrote in message
news:eIBFu9QnGHA.4528@TK2MSFTNGP04.phx.gbl...
>
> You're eliminating the tool that you need to do the job for no apparent
> reason.
The rationale for avoiding OCXs is based on horror stories from several
sources, not on personal experience.
| |
| MyndPhlyp 2006-07-01, 6:55 pm |
|
"Bob Butler" <tiredofit@nospam.ever> wrote in message
news:eIBFu9QnGHA.4528@TK2MSFTNGP04.phx.gbl...
>
> None that I know of. You can return recordsets, arrays, collections,
> whatever.
Cool. That broadens possibilities.
| |
|
|
| Bob Butler 2006-07-01, 6:55 pm |
| "MyndPhlyp" <nobody@homeright.now> wrote in message
news:epzqRwRnGHA.4448@TK2MSFTNGP04.phx.gbl
> "Bob Butler" <tiredofit@nospam.ever> wrote in message
> news:eIBFu9QnGHA.4528@TK2MSFTNGP04.phx.gbl...
>
> The rationale for avoiding OCXs is based on horror stories from
> several sources, not on personal experience.
Then that's a doubly good reason to try it for yourself. User controls can
be daunting at first but they can be extremely useful.
--
Reply to the group so all can participate
VB.Net: "Fool me once..."
| |
| Jan Hyde 2006-07-03, 3:55 am |
| "MyndPhlyp" <nobody@homeright.now>'s wild thoughts were
released on Sat, 1 Jul 2006 11:17:22 -0400 bearing the
following fruit:
>
>
>Any opinions on this proposed solution? Vintage 6-Mar-2002,
>microsoft.pub.vb.winapi.
>
>
>http://groups.google.com/group/micr...fe8fce1f9ef2048
>
>
I haven;t looked at the solution but I have experienced
varous API hacks to achive what you want and most (perhaps
all) have some side effects. You might not even notice the
side effect on one OS but find its vary noticable on
another.
I recall testing a 3rd party product, an oxc, that you drop
on your form and it does all the work for you, it seemed to
work very well (although I no longer have a link to it)
Jan Hyde (VB MVP)
--
To our friend the furniture mover: “Happy Haulidays” (Bob Thaves)
| |
| Jan Hyde 2006-07-03, 3:55 am |
| "MyndPhlyp" <nobody@homeright.now>'s wild thoughts were
released on Sat, 1 Jul 2006 10:38:48 -0400 bearing the
following fruit:
>
>"Bob Butler" <tiredofit@nospam.ever> wrote in message
>news:eIBFu9QnGHA.4528@TK2MSFTNGP04.phx.gbl...
>
>The rationale for avoiding OCXs is based on horror stories from several
>sources, not on personal experience.
>
In my experience most OCX horrors have been due to a badly
written OCX.
Jan Hyde (VB MVP)
--
To our friend the furniture mover: “Happy Haulidays” (Bob Thaves)
| |
| MyndPhlyp 2006-07-03, 7:55 am |
|
"Jan Hyde" <StellaDrinker@REMOVE.ME.uboot.com> wrote in message
news:33jha29n1re76arpp33vtvsn5usesqrh8s@
4ax.com...
>
> I recall testing a 3rd party product, an oxc, that you drop
> on your form and it does all the work for you, it seemed to
> work very well (although I no longer have a link to it)
I may have been playing around with that very thing 'tho you didn't mention
any names. Among the dozen or so "solutions" I managed to locate this
wend, one was called MDIActiveX written by Michael Wallner from Vienna
(vintage: November 2000). His web site seems to have disappeared. I have
since, however, succumbed to the suggestions and warnings posted in this
thread to-date. The strategy has been abandoned, the play book has been
revised, and I'm moving onward to Plan D. (That's why God invented erasers.)
Thanks all.
|
|
|
|
|