BUG: Z-Order Behavior Different with OLE (.OCX) Controls (145731)
The information in this article applies to:
- Microsoft Visual Basic Standard Edition, 32-bit, for Windows 4.0
- Microsoft Visual Basic Professional Edition, 16-bit, for Windows 4.0
- Microsoft Visual Basic Professional Edition, 32-bit, for Windows 4.0
- Microsoft Visual Basic Enterprise Edition, 16-bit, for Windows 4.0
- Microsoft Visual Basic Enterprise Edition, 32-bit, for Windows 4.0
This article was previously published under Q145731 SYMPTOMS
The z-order behavior of a control which is now an OLE (.OCX) control is
different than it was for the equivalent .VBX control in Microsoft Visual
Basic 3.0 for Windows. The OLE (.OCX) control does not overlap (appear on
top of) a windowed control like the PictureBox control at design time. This
change in z-order behavior is especially noticeable when a Visual Basic 3.0
application is imported into Visual Basic 4.0 and the .VBX controls are
upgraded to OLE (.OCX) controls. A control which overlapped a windowed
control is now underneath that control. Using the "Bring to Front" command
on the Edit menu at design time has no effect. Even at run-time most OLE
(.OCX) controls are underneath a windowed control. No matter how the
control is overlapped at design time, at run-time it is always on top of
lightweight controls and usually underneath windowed controls. This is
especially confusing when one of these OLE (.OCX) controls is underneath a
lightweight control at design time.
CAUSE
Due to a design limitation in most OLE (.OCX) controls, these controls do
not have a window handle (hWnd) at design time. This is different than .VBX
controls which have a window handle at design time. Both .VBX and OLE
(.OCX) controls have window handles at run-time. Thus the z-order behavior
of OLE (.OCX) controls is not consistent with the z-order behavior of .VBX
controls because the OLE (.OCX) controls act like lightweight
(non-windowed) controls at design time and windowed controls at run-time.
In addition some controls do not correctly preserve the relative z-order
among windowed controls at run-time, either by forcing themselves on top of
or underneath the other windowed controls.
WORKAROUND
Explicitly set the z-order of the OLE (.OCX) controls at run-time with the
z-order method. There is currently no way to correct this problem at design
time.
STATUS
Microsoft has confirmed this to be a bug in the Microsoft products listed
at the beginning of this article. Microsoft is researching this problem and
will post new information here in the Microsoft Knowledge Base as it
becomes available.
REFERENCES
- Microsoft Visual Basic, Version 4.0, "Programmer's Guide", Appendix C
"Compatibility with Other Versions", "Visual Basic 3.0 for Windows"
section, "Z-Order in OCX Controls" subsection.
NOTE: The second sentence which starts "In Visual Basic 4.0, however,
most OCX controls behave like lightweight controls at run-time,
..." should read "In Visual Basic 4.0, however, most OCX controls
behave like windowed controls at run-time, regardless of the
z-order setting at design time.".
Modification Type: | Major | Last Reviewed: | 12/9/2003 |
---|
Keywords: | kbbug KB145731 |
---|
|