 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Developer Toolkits / June 2004References basics
I'm building my very first setup package for an Access application. I know what references I have. I built a test system with just XP on it and Word as those are the minimum requirements of my intended user group. I noticed that comdlg32.ocx was not on my test system so I included that in my install package (using the Package Wizard in Access 2003 developer extensions). I assumed the install package would put the .ocx in the same directory on the user system as it came from on my system c:\Windows\System 32 but it didn't. So, I have several questions. How can I tweak the install to put the comdlg32.ocx in the correct folder? How about the other references, do I include those to be safe? I really need a link to some in-depth discussion of the package wizard for 'first time' users. The discussions I've found on Microsoft site are accurate (I guess) but very not at all in-depth. Karen Hagerman Practitioner Faculty University of Phoenix kahager@email.uophx.edu Even if you are able to install the OCX to the proper location, a PDW generated installer will not register it. If you are using any references beyond the basics (Access, DAO, and VBA), you'll have to jump through some hoops to get a decent installer generated with PDW. You may be able to avoid some reference isssues by using late binding or API calls instead of a reference. You may find some useful info on web site below under Extras.  SignaturePaul Overway Logico Solutions, LLC www.logico-solutions.com > I'm building my very first setup package for an Access application. I know > what references I have. I built a test system with just XP on it and Word [quoted text clipped - 18 lines] > University of Phoenix > kahager@email.uophx.edu Paul, Thanks, I had already looked at the White paper on the site. My problem is that this is REALLY first time out of the box for me and I just don't understand some of the issues. Karen Even if you are able to install the OCX to the proper location, a PDW generated installer will not register it. If you are using any references beyond the basics (Access, DAO, and VBA), you'll have to jump through some hoops to get a decent installer generated with PDW. You may be able to avoid some reference isssues by using late binding or API calls instead of a reference. You may find some useful info on web site below under Extras. SignaturePaul Overway Logico Solutions, LLC www.logico-solutions.com > I'm building my very first setup package for an Access application. I know > what references I have. I built a test system with just XP on it and Word > as those are the minimum requirements of my intended user group. > > I noticed that comdlg32.ocx was not on my test system so I included that in > my install package (using the Package Wizard in Access 2003 developer > extensions). I assumed the install package would put the .ocx in the same > directory on the user system as it came from on my system c:\Windows\System > 32 but it didn't. > [quoted text clipped - 10 lines] > University of Phoenix > kahager@email.uophx.edu >I noticed that comdlg32.ocx was not on my test system so I included that in >my install package What specifically in comdlg32.ocx are you using? Unless you're using Treeview the following page should give you some alternatives. How do you get rid of troublesome references? http://www.granite.ab.ca/access/referencetroubles.htm 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, Thanks very much. I'm not using treeview but I was using the File Open dialog. I'll look to see if late binding may help and I'll try the API call but I do find the code intimidating and find myself wondering why I can't ever trust Microsoft to be backward compatible with their dll's and ocx's. Karen "Karen" <wonderlover@functiy.com> wrote: >I noticed that comdlg32.ocx was not on my test system so I included that in >my install package What specifically in comdlg32.ocx are you using? Unless you're using Treeview the following page should give you some alternatives. How do you get rid of troublesome references? http://www.granite.ab.ca/access/referencetroubles.htm 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 |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.