Hi,

In the context of a Standard Exe project, I have successfully
implemented the Visual Basic Books Online example, "Scroll Bar Controls
Scenario: Creating a Scrollable Graphics View port".

Within the context of creating an ActiveX DLL, I have cut and pasted the
exact code. However, when I test the component, the scroll bars do not
show up.

I have stepped through the de{*filter*} on both sets of code, and cannot
explain why I see such drastic differences in the dimensions of the two
picture windows while in the ActiveX DLL project.  It's as if the second
picture window is using a totally different unit of measure.  For
example, picture window 1 has dimensions in the thousands, and picture
window 2 has dimensions in the hundreds.

In the Standard Exe environment, both picture windows have dimensions in
the hundreds.

Does anyone have a guess as to why the exact code would behave
differently in the context of the ActiveX DLL programming environment?

Thanks in Advance,

Ann Cook

Hi,

I have just discovered what causes the scroll bars to display, but I cannot
explain why especially since it works for a Standard Exe Project and the
code is directly from the VB example. Could you provide some insight?

Here is the issue....

I have a form named Form1 and picture boxes named Picture1 and Picture2.
Here are a few lines of the code that we can use to discuss the issue.

Private Sub Form_Load()
    Form1.ScaleMode = vbPixels
    Picture1.ScaleMode = vbPixels
    ........
Sub End

When I step through the code on the first line, here is what I think
happens.  The interpreter thinks that Form1 is the first occurrence of a new
instance of the Form1 object, and enters the Form_Load function again (so
something similar to a recursive procedure call has taken place).  After the
Form_Load function completes the 2 executions, the Form ScaleMode is in
Twips.  With the different units of measure the logic in the code concludes
that scroll bars are not required.

If  I remove "Form1." from the first line of code (as well as anywhere else
that I have specifically referred to Form1 in the Form object) resulting in
"ScaleMode = vbPixels" , the Form_Load() function is only executed once and
the scroll bars appear as expected.

Do you know why using Form1 to refer to the Form Object within the Form
Object causes the object to think that it is another instance?  And why can
you refer to the object this way in the Standard Exe Project, but not in an
ActiveX DLL?

I surely appreciate any insights you might have.
Thanks,

Ann Cook

--
Ron Ruble
Raffles Software Development, Inc.

    ActiveX DLLs run in-process, and can be invoked by many
clients. All it takes to load an ActiveX DLL is a reference to
the DLL in the project using it, and an object to reference.
    In an ActiveX server, Form1 is an object. Using the name
in a sub requires a *loaded* instance of the object.
    Since you are in the load event, the currently running
code is not fully loaded, so COM is creating an instance for you.
It has to do this, because it does not know what kind of
object it is, or what initialization is required (COM knows
*nothing* about the internal structure or dependencies of
COM objects; you know it's a VB Form, I know it's a VB form,
COM only knows its a CLSID).
     In a standard EXE, your objects are private objects, so
COM is not loading an instance.

Hi Ron,

Thanks so much for your reply.  Your explanation aligns directly with what I see
happening in the code.  However, I may not have understood your concluding
statement, " In a standard EXE, your objects are private objects, so COM is not
loading an instance." Here's why.

I did the VB Online Books Tutorial, "Creating an ActiveX DLL".  In the tutorial,
it specifically states that the Form is a private class and a client cannot
invoke a form directly.  Therefore, I created a Public class which contains a
Form1 object.  When the class is instantiated, it in turn creates a Form1
object.

Nevertheless, with your explanation and Jim Deutch's, I have discovered what the
difference is, in my case, between the standard Exe and the ActiveX DLL.  The
Standard Exe Project never declared a specific instance of the Form1 object;
therefore, the VB global instance of Form1 was all that was being used
throughout the code.  In the ActiveX DLL project, I specifically declared an
instance of Form1, so when the interpreter saw the reference to Form1 it
proceeded to load the VB global instance.