A few things I hope you can clear up...

[rwallace]

I have no doubt, these three questions will exceed the boundaries of your
discussion, but as they have been most troubling to my development efforts,
I figure they're worth asking, just in case:

1.) When I create my own ActiveX Controls (of which I am quite well versed),
I cannot seem to get the control to automatically insert the [Index as Integer]
argument to events such as Click, DblClick, etc... when the control is augmented
as an array (in other words copying the control in question, and pasting
another - accepting the prompt to create a control array).
This works fine when I use the ActiveX Wizard, but I do not like the way
the wizard documents my code, or uses naming conventions.
When comparing a control made by myself and one made from the wizard, I find
absolutely nothing dsifferent in the code (other than the comments and naming
conventions) What am I doing wrong?
P.S. I haven't deleted the necessary mapping comments above the code blocks.

2.) I have created a fairly extensive framework for my development efforts
and have equally extensive error handling in it... but when I try to write
to the native error log, I am forced to use whatever directory the computer
wishes to write the log to (usually the C:\ root directory). I have experimented
with inserting App.Path to force the directory to be that of my program exe
file, and have also tried creating a variable to store the App.Path and use
it in a similar way - niether approach works. Is there a way to force the
directory used?

3.) When creating an ActiveX control that has a transparent BackStyle (for
use with masked pictures), the original picture (hardcoded in the control
prior to compilation) always appears invisible, regardless of the mask color
and mask picture utilized... when I change or even reload the picture (in
design mode), everything appears as it should... what is the problem?

4.) [just remembered this one, hope you'll let me sneak it in
When using the above control, I have code to resize the control to wrap the
picture whenever it is changed (using the ScaleX and ScaleY methods, converting
HiMetric to Twips)... this works well enough when loaded, but when I try
to respond to the picture being resized by storing the code in the Resize
event, the picture's height is wrapped fine, but not the width... I am certain
the code works (no problems using it in objects other than ActiveX controls)...
I'm stumped.
P.S. If there is a way to make the resizing handles disappear during design
time, this would solve the problem too.

[Tim Patrick]

Your discussion host (that's me) is starting to get an inferiority complex
from the nature of the questions. Like you, I am just a Visual Basic programmer
who has to bang his head against the brick wall of tough programming problems
all the time. I wish I could solve the problems you are having, but it is
difficult when I do not have the entire set of code available. However,
here are some of my thoughts on your issues. If they are useful to you,
great!

1. I have not had the control array problem you are discussing. As you know,
the control array aspect of a custom ActiveX control is not handled primarily
by you, but by the "extender" features of the VB User Control implementation.
I agree that "wizard" code generators are frustrating, but you may be able
to use the wizard simply to generate comparison code. I would generate your
control using the wizard, save it to a "ctl" file, then open the ctl file
in Notepad (or similar program) to see everything that the wizard is putting
in the file. Then compare it to your ctl file. You may see some minor (hidden)
attribute that differs between your version and the wizard version.

2. I assume by "native error log" you mean the App.LogEvents method. If
your application is running on Windows NT or 2000, the logged entries are
placed in the system event log, viewable with the Event Viewer or the Windows
2000 management console. In Windows 9x, the logged entries should appear
in a file you specify through the App.LogPath property. App.Path is not
designed for use with the App.LogEvents command.

3. Windows is funny when it comes to drawing background pictures. I just
read an article that said Microsoft changed the way that background graphics
are drawing between VB5 and VB6. I think the article is in the October 2000
issue of MSDN magazine, but since it is at home and I am at the office....
As you know, the drawing of the form is done internally using WM_PAINT messages,
exposed in VB through the Form_Paint event. If there is a lot of activity
going on in your system, WM_PAINT messages take a back seat to other more
important messages. Perhaps VB is tossing the WM_PAINT messages when it
experiences message overload at the startup of your control. I kind of doubt
that. Still, you may simply have to overcome the problem either by calling
the Me.Refresh method early in the life of the control, or by placing the
picture in a hosted picture control.

4. These computers are just so baffling! Offhand I do not know what the
problem is. You already know that there are different Twips measurements
for X and Y, as exposed through the Screen.TwipsPerPixelX and Screen.TwipsPerPixelY
properties. I would probably put tons of Debug.Print messages in the control
to find out what is really going on. If you change the image to be stored
in a hosted control, as I mentioned in the previous item, that may automatically
solve your problem.
-----
Tim Patrick
tim@vbstyleguide.com