Different Versions of Object Libraries

  • Thread starter Thread starter Phil Reynolds
  • Start date Start date
Thanks, Douglas!

This code worked like a charm. I updated all the code for outlook to late
binding, and added the error checks for err=429.

Thanks so much, now if we could only find late biding for that pesky
tree-view control, good old comctl32.ocx!

Andy
 
ARC said:
Thanks so much, now if we could only find late biding for that pesky
tree-view control, good old comctl32.ocx!
Click to expand...

I've been watching for this one for about six or seven years now.
There is a German commented version where you can purchase the source
code done in API calls. But that's all I'm aware of.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
Hey Tony,

I'm guessing for those of us unfortunate enough to go with a tree-view
control, we're SOL. Hopefully comctl32.ocx is nice to us, at least more nice
than things like common dialogs, fonts, etc. In my case, I use the tree-view
for part categories, so user's can categorize their parts and create their
own categories, and sub-categories (I limit to about 4 deep in the tree, as
the code was a royal pain).

Take care,

Andy
 
Ok, first gotcha with my 2007 install, dealing with the good old tree-view
active x. I have a user with the following:

"Windows 2003 R2 with SP2 running terminal services and connecting via
Citrix Presentation Server 4.5 Hotfix rollup 1"

On my install, I have the file: cmctrl32.ocx installing to: %Sys32%, which
should be the windows\system dir. He's getting an error 438, object doesn't
support this property or method when he loads the screen that has the
treeview control.

Any ideas? The only thing I really changed in my installation script, was I
used to install the file to c:\windows\, but changed it to the windows
system folder.

Sure is too bad there's not a late binding solution for the tree-view. And I
can't think of a great alternative to having part categories with
sub-categories... :(

Andy
 
As a further update... When I thought more on this, I realized that this is
not an active x error exactly. And then it dawned on me that I've seen this
one before. It was right after installing office 2000, apparently there was
a newer version of the cmctrl32.ocx, so instead of the reference showing as
"MS Windows Common Controls 5.0 SP2", it was MS Windows Common Controls 6.
And for whatever reason, 6 put up the error 438, whereas the previous common
controls did not. So I had switched back to common controls 5 and forgot all
about it.

And this all makes sense now, because when I isntall cmctrl32.ocx, I have
the file set to version (so it won't replace if the version is newer), and
of course, the user must have a newer cmctrl32, which is the common controls
6.

I'll include my tree code, as there's something that 6 doesn't like that
common controls 5 had no trouble with:

Public Function SetupTreeView(SetupType As String)
On Error GoTo ErrRtn
'Add Node objects.
Dim f As Form, firstnode As String, nodX As Node, NodX2 As Node, NodX3 As
Node, NodX4 As Node, db As Database, rs As Recordset, rs2 As Recordset,
criteria As String, rs3 As Recordset, rs4 As Recordset, criteria2 As String,
criteria3 As String
' Declare Node variable.
' First node with 'Root' as text.
Set f = Forms!fParts.Form
f!PartCatsTreeView.Nodes.Clear
f!PartCatsTreeView.Nodes.Clear
goSub SetupTree
exitout:
'
Exit Function
'
SetupTree:
Set db = CurrentDb()
Set rs = db.OpenRecordset("qrycboFilter", DB_OPEN_SNAPSHOT)
Set rs2 = db.OpenRecordset("qrycboFilterSub", DB_OPEN_SNAPSHOT)
Set rs3 = db.OpenRecordset("qrycboFilterSub", DB_OPEN_SNAPSHOT)
Set rs4 = db.OpenRecordset("qrycboFilterSub", DB_OPEN_SNAPSHOT)
If Not rs.BOF Then
rs.MoveFirst
firstnode = rs!CatDescription
Do Until rs.EOF
'Tree Level 1, Root
Set nodX = f!PartCatsTreeView.Nodes.Add(, , Chr(34) &
rs!PartCategoryID & Chr(34), rs!CatDescription)
' This next node is a child of Node 1 ("Root").
criteria = "CategoryOfID = " & rs!PartCategoryID
rs2.FindFirst criteria
Do Until rs2.NoMatch
'Tree Level 2
Set NodX2 = f!PartCatsTreeView.Nodes.Add(nodX, tvwChild, Chr(34)
& rs2!PartCategoryID & Chr(34), rs2!CatDescription)
criteria2 = "CategoryOfID = " & rs2!PartCategoryID
rs3.FindFirst criteria2
Do Until rs3.NoMatch
'Tree Level 3
Set NodX3 = f!PartCatsTreeView.Nodes.Add(NodX2, tvwChild,
Chr(34) & rs3!PartCategoryID & Chr(34), rs3!CatDescription)
criteria3 = "CategoryOfID = " & rs3!PartCategoryID
rs4.FindFirst criteria3
Do Until rs4.NoMatch
'Tree Level 4
Set NodX4 = f!PartCatsTreeView.Nodes.Add(NodX3,
tvwChild, Chr(34) & rs4!PartCategoryID & Chr(34), rs4!CatDescription)
rs4.FindNext criteria3
Loop
rs3.FindNext criteria2
Loop
rs2.FindNext criteria
Loop
rs.MoveNext
Loop
End If
rs.Close
rs2.Close
rs3.Close
rs4.Close
db.Close
Return
'cboFilter_NodeClick (Me!cboFilter.Nodes(firstnode))
'Set Me!cboFilter.SelectedItem = Me!cboFilter.ListItems(1)
ErrRtn:
If Err = 94 Or Err = 13 Then
MsgBox "SetupTreeView: You are missing the part type descriptions for
one or more part types. Click on the Setup button, then Part Categories tab
and fill in any missing part type descriptions.", vbCritical, "Missing Part
Category Descriptions"
Exit Function
Else
MsgBox Err.Number & " - " & Err.Description & ", Function:
SetupTreeView", vbCritical
End If
Exit Function
 
ARC said:
I'm guessing for those of us unfortunate enough to go with a tree-view
control, we're SOL. Hopefully comctl32.ocx is nice to us, at least more nice
than things like common dialogs, fonts, etc.
Click to expand...

FWIW, you may already know this, there are replacements for all those other uses of
the MS supplied OCXs.

How do you get rid of troublesome ActiveX Controls/references?
http://www.granite.ab.ca/access/referencetroubles.htm
In my case, I use the tree-view
for part categories, so user's can categorize their parts and create their
own categories, and sub-categories (I limit to about 4 deep in the tree, as
the code was a royal pain).
Click to expand...

Yes, that would be slightly ugly. I'd use the treeview logic a *lot* if it didn't
depend on an OCX.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
ARC said:
Sure is too bad there's not a late binding solution for the tree-view. And I
can't think of a great alternative to having part categories with
sub-categories... :(
Click to expand...

In similar situations I've used continuous forms with drill downs. That is a
continuous form showing all categories, then another form based on the category shown
with a continuous subform off all the sub-categories and so forth.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
Hey Tony,

I had 2 more posts below regarding a problem with treeview on the app I just
released for testing. Can you have a look?

Unfortunately, I can't even duplicate the error because I can't get Common
Controls 6 to load, even if I install the office 2000 developer ocx's.

Thanks!
 
ARC said:
As a further update... When I thought more on this, I realized that this is
not an active x error exactly. And then it dawned on me that I've seen this
one before. It was right after installing office 2000, apparently there was
a newer version of the cmctrl32.ocx, so instead of the reference showing as
"MS Windows Common Controls 5.0 SP2", it was MS Windows Common Controls 6.
And for whatever reason, 6 put up the error 438, whereas the previous common
controls did not. So I had switched back to common controls 5 and forgot all
about it.

And this all makes sense now, because when I isntall cmctrl32.ocx, I have
the file set to version (so it won't replace if the version is newer), and
of course, the user must have a newer cmctrl32, which is the common controls
6.

I'll include my tree code, as there's something that 6 doesn't like that
common controls 5 had no trouble with:
Click to expand...

I doubt the problem is with your code as such. Its the reference being different.
Michael Kaplan has an article on his trigeminal.com website about working with
references. You might, I do emphasize might, be able to fix a different version
problem in an MDE. I doubt it but you could at least take a look at what he has to
say on this topic.

INFO: How to guarantee that references will work in your applications
http://trigeminal.com/usenet/usenet026.asp?1033 (The title is misleading. <smile>)

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
I'll check it out, thanks, Tony! I guess in the short-term, I could update
my install .exe to always replace comctrl32.ocx, regardless of teh version,
to ensure that they have the same one that the developer has.

I was thinking back to the DOS days, and how you would set Path's in the
autoexec.bat. Based on the following I found on references, I wonder if I
should try installing comctrl32.ocx to the folder that my program is
launched from? It seems it there is a way to guarantee that my development
version of comtrl32.ocx will be the one that is used, the problem would be
solved:

1. Access checks to see if the referenced file name is currently loaded in
memory.
2. If not, Access verifies whether the RefLibPaths registry key exists. If
so, Access looks for a named value with the same name as the reference. If
there is a match, Access loads the reference from the path that is pointed
to by the named value.
3. Access next searches the following locations for the referenced file:
-Application Folder (location of Msaccess.exe)
-Current Folder that you see if you click Open on the File menu
-WinDir where the operating system files are running
-System Folder located in the WinDir
-the PATH environment list of folders directly accessible by the system.
4. If the file cannot be found, then a referencing error occurs.


Now #2 above is a bit confusing. If you install the .ocx to your program
folder, and do the self-registering ocx's bit, I wonder if the RefLibPaths
would show my program folder, or Sys32?
 
Hi,

actually MS Windows Common Controls 5.0 has comctl32.ocx name, and
cmctrl32.ocx is some other control, perhaps this is a source of your
problem.
Furthermore - I would suggest you to use MS Windows Common Controls 6 then
5, you will get less compatibility problems

--
Best regards,
___________
Alex Dybenko (MVP)
http://alexdyb.blogspot.com
http://www.PointLtd.com
 
I tried to load common control 6 off the office 2000 developer cd, but it's
still not showing as an option in references.

Also, when I did try common controls 6, I began receiving the error 438
using the code sample in the previous post of mine. I couldn't see anything
wrong with the code, but maybe something changed in referencing the nodes
between v5 and v6 of common controls? Can you have a look at the code?

Also, how can I get the common controls 6 to show as an option in
references? Thanks!
 
Try the following:
remove all of v5 controls from all your forms
remove reference to v5
compact mdb
now open a form in designer and using menu insert-activex control - insert a
treeveiw V6 to your form. This will add a reference to V6 controls also.

so you can use only one version of controls - v5 or v6


--
Best regards,
___________
Alex Dybenko (MVP)
http://alexdyb.blogspot.com
http://www.PointLtd.com
 
ARC said:
I'll check it out, thanks, Tony! I guess in the short-term, I could update
my install .exe to always replace comctrl32.ocx, regardless of teh version,
to ensure that they have the same one that the developer has.
Click to expand...

Not a good idea as you may break some other app.
I was thinking back to the DOS days, and how you would set Path's in the
autoexec.bat. Based on the following I found on references, I wonder if I
should try installing comctrl32.ocx to the folder that my program is
launched from? It seems it there is a way to guarantee that my development
version of comtrl32.ocx will be the one that is used, the problem would be
solved:
Click to expand...

Oh yes, there is a procedure that might work. But I forget the
details. MS added something to Windows XP along those lines.
Creating a zero byte file the same name as your OCX but with an
extension .local?

Nope, that won't work in this situation as this is an MDB we're
dealing with.
DLL/COM Redirection on Windows
http://msdn2.microsoft.com/en-us/library/Aa375142.aspx

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
I had an HP-41C! I loved that thang! RPN and all. That was the first thing I
ever programmed, doing one line at a time on that screen. I remember I
brought it to college and used it in chem lab to input some readings and run
them through an algorithm or whatever. I loved that thang!
 
Tony,

I now have the treeview running spot-on with MSComctrl.ocx. And it now
works perfectly on beta-testers machines, so that is great news. Have you
found any great tricks with the treeviews? I set mine up with the Linestyle1
rwRootLines, and just the plusMinusText. I make the indentation about 200,
as the default of 500 is too much for narrow fields. Did you every try using
the graphics, or the edits? I suppose I could let them change the label, and
then just edit the part description, however, in multi-user, the admin's
probably wouldnt' like user's messing up the descriptions, so I just disable
that.

Take care,

Andy
 
ARC said:
I now have the treeview running spot-on with MSComctrl.ocx. And it now
works perfectly on beta-testers machines, so that is great news. Have you
found any great tricks with the treeviews? I set mine up with the Linestyle1
rwRootLines, and just the plusMinusText. I make the indentation about 200,
as the default of 500 is too much for narrow fields. Did you every try using
the graphics, or the edits?
Click to expand...

No to both. I just adjacent fields.
Create Families from Volunteers User Interface
http://www.granite.ab.ca/access/familiesui.htm

Oh, I set all the treeview properties in code. I right click the tree
view and play with the properties until it looks like what I want.
But then I record them as I go along and set them up on the Form Open
event. Thus if I have to delete the treeview control and insert it
again the code handles that. That was back in A97 days so maybe
things are stabler these days.

There is one trick if you need to clear all the nodes.

nodes.clear can get real slow when dealing with lots of nodes. Try
turning the form's visibility off, do the clear method and turn the
form's visibility back on. Or possibly the painting property.

If you turn the tree control's visibility off, Access will GPF. (Not
sure what version of Access or the Treeview control)

Tom Mapp said "I just set the root node expansion to false, prior to
clearing.".

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
ARC said:
Tony,

I now have the treeview running spot-on with MSComctrl.ocx. And it now
works perfectly on beta-testers machines, so that is great news. Have you
found any great tricks with the treeviews? I set mine up with the Linestyle1
rwRootLines, and just the plusMinusText. I make the indentation about 200,
as the default of 500 is too much for narrow fields. Did you every try using
the graphics, or the edits? I suppose I could let them change the label, and
then just edit the part description, however, in multi-user, the admin's
probably wouldnt' like user's messing up the descriptions, so I just disable
that.

Take care,

Andy
Click to expand...
 
ARC said:
Tony,

I now have the treeview running spot-on with MSComctrl.ocx. And it now
works perfectly on beta-testers machines, so that is great news. Have you
found any great tricks with the treeviews? I set mine up with the Linestyle1
rwRootLines, and just the plusMinusText. I make the indentation about 200,
as the default of 500 is too much for narrow fields. Did you every try using
the graphics, or the edits? I suppose I could let them change the label, and
then just edit the part description, however, in multi-user, the admin's
probably wouldnt' like user's messing up the descriptions, so I just disable
that.

Take care,

Andy
Click to expand...
 
Back
Top