OCX crashes when compiled with binary compatibility

VB6SP6 Win10x64
User control: fafalone's ucShellTree

I compiled the ucShellTree as an OCX and use binary compatibility to avoid multiple ClassIDs for each new compiled OCX.

Problem:

VB6 crashes everytime when i start my test project in the IDE and a form with the control is displayed.
This also happens when i run the test project as an compiled EXE.
I get no crash if i open the form with the control in the IDE and edit some properties.

Step-by-Step:

1. I create a new test project.
2. I added the ucShellTree control to a form.
3. I start the project: CRASH (the VB6 IDE task is gone)

1. I open the test project again and compiled it (EXE).
2. I start the compiled EXE: CRASH (the EXE task is gone)

Info:

I can start the project in the IDE and the run the compiled EXE without crash if i compile the OCX without any compatibility. But this no pratical solution...

Question:

Does anyone know what can be the reason that a OCX with binary compatibility crashes when the control is displayed?
Is this a general OCX issue or does it have something to do with the specific code of the ucShellTree?

Did you try unregistering and removing the old version first?

Quote:

---

Originally Posted by fafalone

Did you try unregistering and removing the old version first?

---

No. I just compiled the OCX with binary compatibility and replaced the OCX without compatibility.

After debugging the compiled OCX with binary compatibility i found out that crash occurred in the function CreateTreeView at the line CreateTreeView = CreateWindowEx(...)

Code:

---

                                                                                                                                 
Private Function CreateTreeView(hwndParent As Long, _                                                                                   
                                                    iid As Long, _                                                                     
                                                    dwStyle As Long, _                                                                 
                                                    dwExStyle As Long) As Long                                                         
  DebugToFile "CreateTreeView_Start"                                                                                                   
  Dim rc As oleexp.RECT ' parent client rect                                                                                           
  Call GetClientRect(hwndParent, rc)                                                                                                   
  DebugToFile "CreateTreeView_1"                                                                                                       
  ' Create the TreeView control.                                                                                                       
  CreateTreeView = CreateWindowEx(dwExStyle, WC_TREEVIEW, "", _                                                                     
                                                dwStyle, 0, 0, rc.Right, rc.Bottom, _                                                   
                                            hwndParent, iid, App.hInstance, 0)                                                     
DebugToFile "CreateTreeView_End"                                                                                                       
                                                                                                                                       
End Function

---

Debug values before CreateWindowEx:

Code:

---

                                                                                                                                 
dwStyle: 1350638121                                                                                                                     
rc.Right: 297                                                                                                                           
rc.Bottom: 340                                                                                                                         
hwndParent: 3348196                                                                                                                     
iid: 100                                                                                                                               
App.hInstance: 285212672

---

But i still have no clue why this crash happens...

I tried to use the OCX ( the one ready made) but it wont even add to the VB6 IDE. I get an error.
Unexpected Error (32810)

Quote:

---

Originally Posted by k_zeon

I tried to use the OCX ( the one ready made) but it wont even add to the VB6 IDE. I get an error.
Unexpected Error (32810)

---

I thought I fixed this one...

That error results when a control is compiled with an oleexpimp.tlb that references a different version of oleexp.tlb than the one installed on the system. Ever since that issue, I've released an updated oleexpimp.tlb compiled against the new oleexp.tlb release. Since I hadn't changed a single byte I didn't test it; but then I thought I fixed it after this issue arose.

--

@Mith, could you please try what I suggested? Unregister the current one, delete it, then compile?

Quote:

---

Originally Posted by fafalone

@Mith, could you please try what I suggested? Unregister the current one, delete it, then compile?

---

I use oleexp.tlb v6.4 with ucShellTree to compile the OCX. What exactly should i test?

Well to avoid the 32810 error k_zeon mentioned you just have to make sure you use the same oleexpimp.tlb that came with oleexp.tlb 6.4, when you're compiling the combined ocx (ucShellTree doesn't use oleexpimp.tlb, but ucShellBrowse does).

But for your problem I was talking about removing the old version. Find that copy that's the registered one (the path VB6 shows in the components reference for it), exit all apps using it, unregister with regsvr32 /u path\to\ucShellTree.ocx (the regsvr32 in SysWOW64, *not* System32), delete it, then compile. From there you should be able to recompile with binary compatibility until that breaks again (new exposed functions, etc, iirc).


IMHO, I can't stand these OCX nightmares. I avoid them unless there's no other option... I'd never use an ocx version when I could use the .ctl version.

I used your ShellTree project from the zip file ucShellTree27.zip

First step (no crashes):

1. I compiled your project to ShellTree.ocx without compatibility.
2. I registered ShellTree.ocx
3. I created a new VB test project and placed the ShellTree control on a form.
4. no crashes using the ShellTree control in the IDE or as an compiled EXE

Second step (crash):

1. I unregistered ShellTree.ocx
2. I changed the OCX compatibility of the ShellTree project to binary and selected the ShellTree.ocx (without compatibility)
3. I compiled ShellTree.ocx with binary compatibility
4. I registered ShellTree.ocx
5. I created a new VB test project and placed the ShellTree control on a form = no crash
6. I compiled the VB test project and started the EXE = crash
7. I started the VB test project in the IDE = crash

No idea then... that the crash is on CreateWindowEx makes even less sense. Don't know if I could solve it even if I could reproduce it, but I'll look into it.

Recommend either using it as a .ctl or using regfree COM.

Quote:

---

Originally Posted by fafalone

Recommend either using it as a .ctl or using regfree COM.

---

I tried the OCX regfree via manifest but it crashes too. Currently i only can use your ucShellTree as a CTL in my project.

I hope you can reproduce the crash and find a fix for the issue...

What is the downside of using it as a .ctl if it works that way?

Quote:

---

Originally Posted by VanGoghGaming

What is the downside of using it as a .ctl if it works that way?

---

just imagine dev teams would use shared CTLs in their projects instead of compiled OCXs and everyone is changing code in the CTLs at the same time...:eek:

You also can run into the same problem if you work alone on several projects at the same time which use and share the same CTLs...at some point you lose track or forget about the sharing and voila...chaos

Another option while a solution for this is pending; could try the tB version... it's several versions ahead anyway. 32bit compiled version can be used in VB6. I posted an alpha test version of 2.9.2 that incorporates the latest bug fixes you pointed out and new features FileExtensions (UseExplorer, AlwaysShow), .CheckedPathCount property. Plus the v2.8 changes; many new features+bug fixes. ShellControls GitHub -- it's ucShellTreeOcx.twinproj. Must use tB Beta 423; the newer versions from this week have a bug that breaks ucShellTree; must run as admin to register to HKEY_LOCAL_MACHINE which is required for VB6 to see it. I haven't tested it myself but will later today.

Quote:

---

Originally Posted by fafalone

Another option while a solution for this is pending; could try the tB version... it's several versions ahead anyway. 32bit compiled version can be used in VB6. I posted an alpha test version of 2.9.2 that incorporates the latest bug fixes you pointed out and new features FileExtensions (UseExplorer, AlwaysShow), .CheckedPathCount property. Plus the v2.8 changes; many new features+bug fixes. -- it's ucShellTreeOcx.twinproj.

---

Sounds good, but I dont have TwinBasic so i guess i have to wait until you release a classic VB6 update for ucShellTree!

Any thoughts about the time frame for the next VB6 update?

BTW: Is the ExpandZip bug fixed with v2.9.2? With v2.7 ExpandZip=false still expands zip files...

tB has a free community edition with no limits that matter here.

https://github.com/twinbasic/twinbas...ag/beta-x-0423

Portable, just extract and run. No install.

I don't know when I'll update the vb6 version again.

Quote:

---

Originally Posted by fafalone

I don't know when I'll update the vb6 version again.

---

Is the ExpandZip bug fixed with v2.9.2? If so, can you show me the changes so I can update the VB6 control?

Expanding a zip when ShowFiles = True is by design; as I explained it's more of a poorly named property issue.

What I'll do for you is add a module level property, mNeverExpandZip, in the User Options section up top below the changelog.

Then in TVExpandFolder,

Code:

---

                    If fDisable = 0& Then
                        If bFav = False Then
                            If (bZip = False) Or ((bZip = True) And (mNeverExpandZip = False)) Then 
                                If (lAtr And SFGAO_HASSUBFOLDER) = SFGAO_HASSUBFOLDER Then
                                    If (TVEntries(nCur).bZip = False) Or ((TVEntries(nCur).bZip = True) And (mExpandZip = True)) Then
                                        tVI.cChildren = 1
                                        tVI.Mask = tVI.Mask Or TVIF_CHILDREN
                                    End If
                                Else
                                    If (mShowFiles = True) Then
                                        If bFolder = True Then
                                            If FolderIsEmpty(siChild) = False Then
                                                tVI.cChildren = 1
                                                tVI.Mask = tVI.Mask Or TVIF_CHILDREN
                                            End If
                                        End If
                                    End If
                                End If
                            End If
                        End If
                    End If

---

and in TVAddItem,

Code:

---

        If fDisable = 0& Then
            If (bZip = False) Or ((bZip = True) And (mNeverExpandZip = False)) Then
                If (lAtr And SFGAO_HASSUBFOLDER) = SFGAO_HASSUBFOLDER Then
                    If (TVEntries(nCur).bZip = False) Or ((TVEntries(nCur).bZip = True) And (mExpandZip = True)) Then
                        tVI.cChildren = 1
                        tVI.Mask = tVI.Mask Or TVIF_CHILDREN
                    End If
                Else
                    If (mShowFiles = True) Then
                        If bFolder = True Then
                            If FolderIsEmpty(siChild) = False Then
                                tVI.cChildren = 1
                                tVI.Mask = tVI.Mask Or TVIF_CHILDREN
                            End If
                        End If
                    End If
                End If
            End If
        End If

---

Quote:

---

Originally Posted by fafalone

What I'll do for you is add a module level property, mNeverExpandZip, in the User Options section up top below the changelog.

---

It works! Thank you very much!

Quote:

---

Originally Posted by fafalone

IMHO, I can't stand these OCX nightmares. I avoid them unless there's no other option... I'd never use an ocx version when I could use the .ctl version.

---

I tried your CTL approach instead of the OCX and now i run into a problem when i want to use the CTL with another project:

I created a form with the CTL on it. This form should be used with different projects because i dont want to make a copy of the form and the CTL for every project = maintenance hell...thats the reason i only use OCX files and never CTLs in a project.

The problem:

I added the shared form & CTL to the project1 and everything runs fine.
Now i added the shared form & CTL to project2 and i got many error messages:

Code:

---

Line 24: Class project1.ucShellTree of control ucTree was not a loaded control class.
Line 30: The property name _ExtentX in ucTree is invalid.
Line 31: The property name _ExtentY in ucTree is invalid.
Line 32: The property name InfoTipOnFiles in ucTree is invalid.
Line 33: The property name SingleClickExpand in ucTree is invalid.
Line 34: The property name PlayNavigationSound in ucTree is invalid.
Line 35: The property name ShowFavorites in ucTree is invalid.
Line 36: The property name LabelEditRename in ucTree is invalid.
Line 38: The Autocheck property name in ucTree is invalid.
Line 39: The property name DisableDragDrop in ucTree is invalid.
Line 40: The property name ShowHiddenItems in ucTree is invalid.
Line 41: The property name ShowSuperHidden in ucTree is invalid.
Line 42: The property name EnableShellMenu in ucTree is invalid.

---

The reason for the error message is simple, VB saves the project name in the frm-file with the CTL:

Code:

---

  Begin project1.ucShellTree ucTree
      Height          =  3750
      Left            =  675
      TabIndex        =  11
      Top            =  435
      Width          =  3555
      _ExtentX        =  6271
      _ExtentY        =  6615
      InfoTipOnFiles  =  0  'False
      SingleClickExpand=  -1  'True
      PlayNavigationSound=  0  'False
      ShowFavorites  =  0  'False
      LabelEditRename =  0  'False
      BorderStyle    =  0
      Autocheck      =  0  'False
      DisableDragDrop =  -1  'True
      ShowHiddenItems =  1
      ShowSuperHidden =  1
      EnableShellMenu =  0  'False
  End

---

With an OCX this problem will not happen but i cant use the ucShellTree as an OCX because of the binary compatibility problem.

How do you do this with all your projects? I just guess you will have a minimum of 2 projects that share the same form with same CTL on it...

A .ctl will be compiled into the EXE while an OCX will always have to be shipped and registered separately. You absolutely do not want to use any OCX that is not already present by default on the target machine.

You can use a shared .ctl/.ctx, but not a shared form, that's where the problem is. I'm very surprised if it's not the same with .ocx.

Quote:

---

Originally Posted by fafalone

You can use a shared .ctl/.ctx, but not a shared form, that's where the problem is. I'm very surprised if it's not the same with .ocx.

---

You can use shared forms with an OCX because it will use the OCX library name for the control references, not the VB project name. e.g.:

Code:

---

VERSION 5.00
Object = "{7CAC59E5-B703-4CCF-B326-8B956D962F27}#19.3#0"; "Codejock.ReportControl.Unicode.v19.3.0.ocx"
Begin VB.Form Form1
  Caption        =  "Form1"
  ClientHeight    =  3710
  ClientLeft      =  40
  ClientTop      =  380
  ClientWidth    =  6550
  LinkTopic      =  "Form1"
  ScaleHeight    =  3710
  ScaleWidth      =  6550
  StartUpPosition =  3  'Windows Default
  Begin XtremeReportControl.ReportControl ReportControl1
      Height          =  2530
      Left            =  240
      TabIndex        =  0
      Top            =  330
      Width          =  3490
      _Version        =  1245187
      _ExtentX        =  6156
      _ExtentY        =  4463
      _StockProps    =  64
      FreezeColumnsAbs=  0  'False
  End
End

---

Well at least as long as your shared form isn't referencing or calling anything else that might only be in one of the sharing projects.