I am new to using ocx's and dll's. The VB6 application that I just inherited uses more than 10 dll's and an ocx. They are all located in the same folder.

I wanted to see what happens if they are moved to a different folder and what it takes to point the exe to the new folder. I want to become familiar with the error messages that are produced and with fixing the problems.

The dll'd seem to be easy to work with. If I move a dll to a different folder, all I hve to do is to register the dll from the new folder. This seems to automatically unregister the dll from the previous folder and register it from the new folder.

The ocx is not so well behaved, i.e., I don't know how to get it to behave well. I am going to play around with it some more but would appreciate instructions on what it takes to move ocx from folder to folder.

I have had to delete the form containing the control provided by the ocx a lot. I want to do this only when absolutely essential.

Also, when I do a Project->References, I see several versions of the ocx, some in folders no longer present. As I was learning the application, I created several of these. How can I delete these? In general, I am looking for hints on working with ocx's. Thanks.

A question related to this topic:

The project I inherited has 18 dll's and an ocx. After each stage of development, the application is packaged using the Package and Deployment Wizard to create install files. In other words, even if only the VB part changes or only one dll changes, the entire package is recreated. Aren't some of the benefits of using dll's lost doing things this way? (No other application can benefit from these dll's -- these are all highly specific to the application.) Can't a dll be released by itself?

Something to try: Keep the .frm file, but delete the .frx file. When you re-open the app, the IDE will rebuild the .frx from the .frm.

I'm not sure there won't be some collateral damage—for instance, and image list might lose the images—but try it.

Well, no.. Dll can be use to separate each part of the system. And other app still can benefits for it, I don't see why not...

And a dll can be released by itself. But if nobody will use it, what's the point?

HTH

Gonzalo

================================================== =========
Read this if you want to know how to get a correct reply for your question:
http://www.catb.org/~esr/faqs/smart-questions.html
^^Took that from dparsons signature and he Took that from planoie's profile
================================================== =========
My programs achieved a new certification (can you say the same?):
WORKS ON MY MACHINE
http://www.codinghorror.com/blog/archives/000818.html
================================================== =========
I know that CVS was evil, and now i got the proof:
http://worsethanfailure.com/Articles...-Hate-You.aspx
================================================== =========

> I'm not sure there won't be some collateral damage—for instance, and image list might lose the images—but try it.

This scares me.

> Something to try: Keep the .frm file, but delete the .frx file. When you re-open the app, the IDE will rebuild the .frx from the .frm.

What would this potentially accomplish? Thanks.

There is another way to do this. You can modify the frm files in any notepad. You are looking for the first line, the one that defines the version of ocx and dll. The easy way to do this. Close the project, (that also has some definition in the begining of the file, but edit it). Start a new app, add the references and controls you need, and then copy the lines that defines that dll and ocx to your old project, overwritting the one that are inside them.

did I explain it clearly?

HTH

Gonzalo

================================================== =========
Read this if you want to know how to get a correct reply for your question:
http://www.catb.org/~esr/faqs/smart-questions.html
^^Took that from dparsons signature and he Took that from planoie's profile
================================================== =========
My programs achieved a new certification (can you say the same?):
WORKS ON MY MACHINE
http://www.codinghorror.com/blog/archives/000818.html
================================================== =========
I know that CVS was evil, and now i got the proof:
http://worsethanfailure.com/Articles...-Hate-You.aspx
================================================== =========

Gonzalo,

You are giving some crucial hints. Let me try it out. Thanks.

Shaker

Well, one crucial thing it would accomplish is keeping all the controls and their positions, sizes, etc., and the event code that has been written for them. That could be a big time saver, if you find that you are in the position where previously you had to delete the entire form.

Gonzalo,

If you edit the .frm, does the .frx reflect that change well enough for everything to function properly? I’m specifically wondering about controls that store their data in the .frx, like image lists.

Well, I have done it several times, and never had problems with the frx, since it's store only the binary data, and the controls are the same. The only potential problem I can think off is if you are using a third party control that changes a lot between versions, but it doesn't happens with ms controls.
I did it with forms that have imagelist and didn't have any problem, but you can always save a backup before doing it.

HTH

Gonzalo

================================================== =========
Read this if you want to know how to get a correct reply for your question:
http://www.catb.org/~esr/faqs/smart-questions.html
^^Took that from dparsons signature and he Took that from planoie's profile
================================================== =========
My programs achieved a new certification (can you say the same?):
WORKS ON MY MACHINE
http://www.codinghorror.com/blog/archives/000818.html
================================================== =========
I know that CVS was evil, and now i got the proof:
http://worsethanfailure.com/Articles...-Hate-You.aspx
================================================== =========

So to paraphrase: You’re saying that the .frm will specify the packaged code that will use the .frx’s data, but the .frx only contains the data & will be happy to provide it to any reference in the .frm that properly asks for it?