Can I use/reference an OCX in a different way?

Hi All

I use the MSFLEXGRD.OCX file in my VB6 app so that I can utilise this file's
grid-like features.

When I originally created my app the idea was that the user would use my
installer (used InnoSetup to create it) and at the same time as installing
my files, shortcuts, etc it would also install this OCX file into the system
folder and register it.

Now this is fine, but due to the user's that are using my app and the
infrastructure that they are working in, I can't do the install method and
have to go the portable route. This is easy for my app and data as they all
reside within the one folder, but my one stumbling block is that I've got to
supply the user with a little installer that installs this OCX and registers
it, which makes the whole concept of being a portable a lie.

Now the reason why this is a faff is because the users are teachers in a
school and they may use upto 70 diff machines (I kid you not they have to
find the next available machine!!) to use my portable app, but this means
that the technician in school has to go round and install the support files
installer (ie the OCX installer) on 70 odd machines and make sure he
installs it on every new machine that they use. This becomes a real faff
and I'm none too popular with the technicians!!

I can't install and register the OCX via the app, as 9 out of 10 teachers
don't have admin rights to install on a machine.

My query is therefore, can I put the MSFLXGRD.OCX in my portable folder and
simply call/use it within my app without having to put it in the system
folder and register it????

Thanks

On 29 Oct, 18:48, "Mojo" <ple...@dont.spam.com> wrote:

> My query is therefore, can I put the MSFLXGRD.OCX in my
> portable folder and simply call/use it within my app
> without having to put it in the system folder and
> register it????

If your app is going to be run on WinXP or later then the answer is
Yes. You can use Regfree COM, commonly known as XCopy deployment. To
do so you need to create a manifest file which can be distributed with
your compiled VB6 exe file (or alternatively embedded into it). Any
components (such as the MSFLXGRID.OCX or RICHTX32.OCX or whatever else
your app needs) can then be simply placed in the same folder as your
VB6 compiled exe file (together with whatever other supporting files
you are already placing there), and the whole folder sent to your
user. When your VB6 compiled exe file is run at the user's end then it
will automatically use the OCXs in its own folder, without them
needing to be copied anywhere else or registered or whatever.

The process of creating the manifest file, and of embedding it into
your compiled exe if you wish, is made extremely simple by a very nice
tool called MMM (Make My Manifest), which will analyze your VB6
project files for you and automatically create (and if required embed)
the required manifest file. It really is a very useful tool, and it
takes all the hard work out of it for you. The only version I have
used myself is version 6.6 and it works really well, although I think
it is up to about version 7 by now. You can download it at:

http://mmm4vb6.atom5.com/

Mike

Hi Mike

This seems great, but I can't see how it can work :0)

I downloaded MMM 0.7, selected my project and it created the manifest file
(looks like a very short xml file :0), but how does it all link together??

My portable folder structure is as follows:

root folder
> myapp.exe
> my reports (folder)
> my exports (folder)
> my imports (folder)
> system files (folder)

The 3 x my... reports are simply empty folders that my app uses at run-time.

The system files folder contains things like word doc templates that I use
and external bitmap images.

I like to keep things tidy so are we saying that I have to put the required
OCX file, the manifest file and the exe all in my system files folder and
then create a shortcut to my exe in the root area rather than the actual
exe???

Is there anyway I can keep my exe where it is, but put the OCX and manifest
in the system files folder??

Sorry for being a complete newbie on this :0)

Many thanks

"Mike Williams" <gagamomo@yahoo.co.uk> wrote in message
news:a271a840-57df-4a9b-8e96-9a698ebe8a54@s15g2000yqs.googlegroups.com...
On 29 Oct, 18:48, "Mojo" <ple...@dont.spam.com> wrote:

> My query is therefore, can I put the MSFLXGRD.OCX in my
> portable folder and simply call/use it within my app
> without having to put it in the system folder and
> register it????

If your app is going to be run on WinXP or later then the answer is
Yes. You can use Regfree COM, commonly known as XCopy deployment. To
do so you need to create a manifest file which can be distributed with
your compiled VB6 exe file (or alternatively embedded into it). Any
components (such as the MSFLXGRID.OCX or RICHTX32.OCX or whatever else
your app needs) can then be simply placed in the same folder as your
VB6 compiled exe file (together with whatever other supporting files
you are already placing there), and the whole folder sent to your
user. When your VB6 compiled exe file is run at the user's end then it
will automatically use the OCXs in its own folder, without them
needing to be copied anywhere else or registered or whatever.

The process of creating the manifest file, and of embedding it into
your compiled exe if you wish, is made extremely simple by a very nice
tool called MMM (Make My Manifest), which will analyze your VB6
project files for you and automatically create (and if required embed)
the required manifest file. It really is a very useful tool, and it
takes all the hard work out of it for you. The only version I have
used myself is version 6.6 and it works really well, although I think
it is up to about version 7 by now. You can download it at:

http://mmm4vb6.atom5.com/

Mike

On 29/10/2009 18:48, Mojo wrote:
> My query is therefore, can I put the MSFLXGRD.OCX in my portable folder and
> simply call/use it within my app without having to put it in the system
> folder and register it????

Yes.

--
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team

iCode Systems

On 29 Oct, 20:53, "Mojo" <ple...@dont.spam.com> wrote:

> Hi Mike. This seems great, but I can't see how it
> can work :0) I downloaded MMM 0.7, selected my project
> and it created the manifest file (looks like a very
> short xml file :0), but how does it all link together??

It works by creating a manifest file which informs Windows of the
details of the controls (OCXs) that your program is using. The
manifest file MUST have the same name as your compiled VB6 exe file
(including the extension) and it must live in the same folder. For
example, if the name of your compiled VB6 exe file is myapp789.exe
then the name of the manifest file MUST be myapp789.exe.manifest and
both files must be in the same folder. Then, when the user double
clicks your myapp789.exe file (or perhaps double clicks a shortcut to
it) then the Windows operating system automatically checks to see if
there is an appropriately named manifest file in the same folder as
the compiled exe, and if there is then it causes the system to use the
OCXs that are referenced in the manifest file. Those OCXs must of
course live where the manifest file is telling Windows that they live.
If you look in the manifest file in a text editor then you will see
that only the filename is specified for the OCX (not a path) and so
the OCX must also live in the same folder as both the manifest file
and the VB6 compiled exe.

Having said that, I must admit that I have only used MMM for a few
simple test apps and I've not delved too deeply into it, mostly on the
grounds that I am simply a hobbyist and I do not normally have the
need to distribute stuff that I write, so I do not really know a great
deal about it, other than the fact that it works fine in the few
simple tests that I've thrown at it. If you want to carry out further
tests of your own then perhaps the best way is to create the folder
containing the files we have just talked about (where the compiled VB6
exe file and the manifest file and the OCXs it needs all live in the
same root folder) and then make sure it runs. Then use the DOS Command
window (you need to run the DOS Command window by right clicking its
shortcut and selecting Run as Administrator, even if you are the
administrator, if you're using Vista) and manually unregister the OCX,
for example in the DOS window type:

regsvr32 /u c:\windows\system32\msflxgrd.ocx

You should get a message box telling you that DLLUnregisterServer
succeeded. Thereafter, everything else on your machine which uses
msflxgrd.ocx should fail to work, but your own compiled VB6 program
(the one in the folder containing the manifest file and a copy of
msflxgrd.ocx file) should still work fine. You can then test MMM in
various ways and you will immediately know whether what you are doing
has succeeded or not because if you do something wrong or something
that is not going to work then your compiled VB6 program will no
longer work when you run it. Once you have completed all your tests
you can simply register the ocx on your system again (enter the same
as the above into the DOS window, without the /u flag).

In fact, I've just tried that on a simple test app of my own (using a
RichTextBox which requires richtx32.ocx) and after unregistering it in
the DOS window all other VB apps that use a RichTextBox failed to
work, but my test app with the manifest file worked as normal when I
ran it). I then moved the richtx32.ocx file out of the folder
containing my exe and the manifest file and into a sub folder which I
named "support". Naturally, and exactly as I expected, the test app
then failed to run. Then I loaded the manifest file into a text editor
and I changed the line:

<file name="richtx32.ocx">

So that it instead became:

<file name="support/richtx32.ocx">

I then double clicked my compiled exe file to run it again, and this
time it worked fine. So, it definitely is possible to move the OCX
files into a sub folder, but you must also manually edit the manifest
file so that the name of the sub folder is specified, as in the above
example.

So, in part answer to your question, you certainly can move the OCX
files into a sub folder, provided that you edit the manifest file
accordingly, but (at least as far as I have got so far) you still need
to keep the manifest file itself in the same folder as your compiled
VB exe file.

One other point worthy of note is that you can instruct MMM to embed
the manifest file into your compiled exe file if you wish (you should
find an option for that somewhere), and if you do that then you do not
need a separate manifest file at all (because it is embedded into your
exe). However, although that at first seems like a full solution to
your most recent question it doesn't actually work out like that
because if you embed the manifest file into your exe then you cannot
manually edit it afterwards to include the name of your desired sub
folder (or at least you cannot easily do so). I'm fairly sure that
there will be a solution to that problem though (a few random thoughts
are already condensing inside my head as I write!). I'm not sure
whether I will ever get the time to look into that side of things
(very busy here all the time, despite the fact that I am a retired
pensioner!) but if I do find the time and if I do come up with
anything then I will let you know.

By the way, there was another possible solution posted on the other
group by Olaf Schmidt when he suggested that you could use a program
called MoleBox to wrap your app up into a single executable. MoleBox
is a commercial product though, but if you intend to make a lot of use
of it then it might be worth purchasing (I've just had a quick look
and it costs about 100 Euros, which is reasonable for such a program).
There was one other commercial program which did a similar thing (I
can't remember offhand what it was called) but the company that sold
it went out of business (or perhaps change their name to something
else!)

Anyway6, I hope I've been of some help to you. If I get the time to
look a bit more deeply into MMM and if I come uip with anything else
then I'll let you know.

Mike






>
> My portable folder structure is as follows:
>
> root folder
> *> myapp.exe
> *> my reports (folder)
> *> my exports (folder)
> *> my imports (folder)
> *> system files (folder)
>
> The 3 x my... reports are simply empty folders that my app uses at run-time.
>
> The system files folder contains things like word doc templates that I use
> and external bitmap images.
>
> I like to keep things tidy so are we saying that I have to put the required
> OCX file, the manifest file and the exe all in my system files folder and
> then create a shortcut to my exe in the root area rather than the actual
> exe???
>
> Is there anyway I can keep my exe where it is, but put the OCX and manifest
> in the system files folder??
>
> Sorry for being a complete newbie on this :0)
>
> Many thanks
>
> "Mike Williams" <gagam...@yahoo.co.uk> wrote in message
>
> news:a271a840-57df-4a9b-8e96-9a698ebe8a54@s15g2000yqs.googlegroups.com...
> On 29 Oct, 18:48, "Mojo" <ple...@dont.spam.com> wrote:
>
> > My query is therefore, can I put the MSFLXGRD.OCX in my
> > portable folder and simply call/use it within my app
> > without having to put it in the system folder and
> > register it????
>
> If your app is going to be run on WinXP or later then the answer is
> Yes. You can use Regfree COM, commonly known as XCopy deployment. To
> do so you need to create a manifest file which can be distributed with
> your compiled VB6 exe file (or alternatively embedded into it). Any
> components (such as the MSFLXGRID.OCX or RICHTX32.OCX or whatever else
> your app needs) can then be simply placed in the same folder as your
> VB6 compiled exe file (together with whatever other supporting files
> you are already placing there), and the whole folder sent to your
> user. When your VB6 compiled exe file is run at the user's end then it
> will automatically use the OCXs in its own folder, without them
> needing to be copied anywhere else or registered or whatever.
>
> The process of creating the manifest file, and of embedding it into
> your compiled exe if you wish, is made extremely simple by a very nice
> tool called MMM (Make My Manifest), which will analyze your VB6
> project files for you and automatically create (and if required embed)
> the required manifest file. It really is a very useful tool, and it
> takes all the hard work out of it for you. The only version I have
> used myself is version 6.6 and it works really well, although I think
> it is up to about version 7 by now. You can download it at:
>
> * *http://mmm4vb6.atom5.com/
>
> Mike

On 29 Oct, 20:53, "Mojo" <ple...@dont.spam.com> wrote:

> Is there anyway I can keep my exe where it is, but
> put the OCX and manifest in the system files folder??

Further to my previous post in which I explained how to have your exe
and the manifest file in the main folder (with the OCX in your support
folder) I have since figured out a way of having /only/ your exe file
in the main folder. If you're still interested in doing this and if
you haven't yet figured out how to do it then post again.

Mike

Hi Mike

As always, many thanks for your time and assistance.

Unfortunately I'm pants at this!!! :0) How did you manage to get the
manifest into a sub-folder??

Rgds

"Mike Williams" <gagamomo@yahoo.co.uk> wrote in message
news:36e58490-abd8-40c9-90b1-729b84785c5c@d10g2000yqh.googlegroups.com...
On 29 Oct, 20:53, "Mojo" <ple...@dont.spam.com> wrote:

> Is there anyway I can keep my exe where it is, but
> put the OCX and manifest in the system files folder??

Further to my previous post in which I explained how to have your exe
and the manifest file in the main folder (with the OCX in your support
folder) I have since figured out a way of having /only/ your exe file
in the main folder. If you're still interested in doing this and if
you haven't yet figured out how to do it then post again.

Mike

Err... thanks Dee

Is that it?


"Dee Earley" <dee.earley@icode.co.uk> wrote in message
news:4aeaac24$0$350$7b0f0fd3@reader.news.newnet.co .uk...
On 29/10/2009 18:48, Mojo wrote:
> My query is therefore, can I put the MSFLXGRD.OCX in my portable folder
> and
> simply call/use it within my app without having to put it in the system
> folder and register it????

Yes.

--
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team

iCode Systems

On 1 Nov, 12:58, "Mojo" <ple...@dont.spam.com> wrote:

> Hi Mike. As always, many thanks for your time and
> assistance. Unfortunately I'm pants at this!!! *:0)
> How did you manage to get the manifest into a
> sub-folder??

The first method i tried seemed to work okay, but it involved a fair
amount of messing about with the Windows registry and it was too prone
to errors, so I began to look for a different way. I decided that it
might be best to get MMM to embed tha manifest into the compiled VB
exe file and to then edit the resultant exe file in order to change
the various references. This turned out to be not quite as easy as I
thought, because I don't know exactly how the manifest is embedded and
I discovered that until I learn more about it I should make sure that
I do not do anything that changes the overall length of the file
(because that stops it from working). Therefore the method I have come
up with so far can be regarded as nothing more than a kludge really,
but it does seem to work well. Here is the kludge I'm currently using,
which may or may not suit your purposes. It looks like a lot when you
read it, but it isn't really, and much of it is to test whether it
works or not and it is really quite simple to do:

1. Run MMM and select your project and create a MMM package folder in
the normal way, but make sure that you choose the option instructing
MMM to embed the manifest into your compiled exe. MMM will create a
package folder containing a copy of your exe file and of any OCXs you
use (richtx32.ocx in this example). There will not be a manifest file
because the manifest will be embedded into the exe file. Double click
the exe file in the MMM package folder to make sure that it runs okay.
At this stage the ocx file is in the same folder as the compiled VB
exe file, and it will not work if you move in to into another folder.

2. Now, purely for testing purposes, use a DOS box (Run the DOS box as
Admin in Vista) and manually unregister the main system OCX file. In
this specific example you would enter the following into the DOS box
(assuming that your own system32 folder is in c:\windows):

regsvr32 /u c:\windows\system32\richtx32.ocx

You should receive a message to the effect that the file was
unregistered successfully.

3. Now double click your VB6 exe file in the MMM package folder to
make sure that it still runs okay, even though the main system OCX has
been unregistered. You should find that the exe file in the MMM
package folder works fine but that any other VB6 project (or compiled
exe) which uses the RichTextBox control fails to work (because you
have unregistered richtx32.ocx).

4. Now you need to modify the compiled exe file that MMM created in
the MMM package folder so as to enable you to move the MMM package OCX
file (richtx32.ocx in this example) out of the main MMM package folder
and into a sub folder in such a way that the compiled exe still works.
To do this, start a new VB project and run the following code on the
compiled exe file that MMM created for you, the one in which it
embedded the manifest. Change the hard coded path in the Open
statement in the following code accordingly and change the s1 and s2
strings to whatever OCX you have used (use the same code for all other
OCXs you have used in the project). The string s1 must be exactly as
shown, except that it should contain the name of the OCX you have used
yourself (in this example it is the richtx32.ocx). The string s2 is
exactly the same as the string s1, except that the first four
characters of the ocx name are replaced by OCX\ (as in the example):

Dim s1 As String, s2 As String, s3 As String
Open "c:\myproject\MMMPack\myproject.exe" For Binary As 1
s1 = Space$(LOF(1))
Get 1, 1, s1
s2 = "<file name=""richtx32.ocx"">"
s3 = "<file name=""OCX\tx32.ocx"">"
s1 = Replace(s1, s2, s3, vbTextCompare)
Put 1, 1, s1
Close 1

5. When you have run the above code, again double click your VB6 exe
file in the MMM package folder. This time you should find that it
fails to run (because it no longer contains the correct reference in
the embedded manifest file which the above code has just edited).

6. Now create a new folder in your MMM Package folder and rename the
new folder OCX and manually move the ocx file (richtx32.ocx in this
specific example) out of the MMM Package folder and into the new OCX
folder that you just created. Then manually rename the ocx file by
removing the first four characters of its name (for example, rename
richtx32.ocx to tx32.ocx).

9. Double click your exe file in the MMM package folder. You should
find that it now runs okay again, even though the (renamed) OCX file
is now in the sub folder rather than the main folder.

10. Once you have finished and have checked that it works okay then
you use a DOS box to manually re register the main system OCX (again
making sure that you run the DOS box as Admin in Vista). For this
specific example you would enter the following into the DOS box:

regsvr32 c:\windows\system32\richtx32.ocx

As I've said, this is really just a kludge at this stage, but it does
seem to work okay.

Mike

Hi Mike

Many, many thanks for this.

I also followed this same kind of path in my testings, but when it came to
mod-ing the embeded manifest I created kludge #2 ! :0)

I created the manifest file 'unembeded', edited it to the sub-folder path
and modded bits of text to make the entire xml 640 bytes in size. I did
this to create my master 'text block'.

I then ran MMM again, but this time embed the manifest in my exe.

I then used a resource editor (XN resourced editor if this makes a diff!!!)
and edited the Manifest resource part so tha the text followed the same
character by character format of my text block.

This is also fiddly :0), but as you said, this creates the effect that I'm
after and providing Vista and 7 don't have any indigestion problems, this is
going to be a life saver when it comes to passing on to techies for
install!!

Once again, many thanks for this.

Rgds

Mojo

"Mike Williams" <gagamomo@yahoo.co.uk> wrote in message
news:6928742f-b3fe-401a-981b-2ea2d49e2b28@r5g2000yqb.googlegroups.com...
On 1 Nov, 12:58, "Mojo" <ple...@dont.spam.com> wrote:

> Hi Mike. As always, many thanks for your time and
> assistance. Unfortunately I'm pants at this!!! :0)
> How did you manage to get the manifest into a
> sub-folder??

The first method i tried seemed to work okay, but it involved a fair
amount of messing about with the Windows registry and it was too prone
to errors, so I began to look for a different way. I decided that it
might be best to get MMM to embed tha manifest into the compiled VB
exe file and to then edit the resultant exe file in order to change
the various references. This turned out to be not quite as easy as I
thought, because I don't know exactly how the manifest is embedded and
I discovered that until I learn more about it I should make sure that
I do not do anything that changes the overall length of the file
(because that stops it from working). Therefore the method I have come
up with so far can be regarded as nothing more than a kludge really,
but it does seem to work well. Here is the kludge I'm currently using,
which may or may not suit your purposes. It looks like a lot when you
read it, but it isn't really, and much of it is to test whether it
works or not and it is really quite simple to do:

1. Run MMM and select your project and create a MMM package folder in
the normal way, but make sure that you choose the option instructing
MMM to embed the manifest into your compiled exe. MMM will create a
package folder containing a copy of your exe file and of any OCXs you
use (richtx32.ocx in this example). There will not be a manifest file
because the manifest will be embedded into the exe file. Double click
the exe file in the MMM package folder to make sure that it runs okay.
At this stage the ocx file is in the same folder as the compiled VB
exe file, and it will not work if you move in to into another folder.

2. Now, purely for testing purposes, use a DOS box (Run the DOS box as
Admin in Vista) and manually unregister the main system OCX file. In
this specific example you would enter the following into the DOS box
(assuming that your own system32 folder is in c:\windows):

regsvr32 /u c:\windows\system32\richtx32.ocx

You should receive a message to the effect that the file was
unregistered successfully.

3. Now double click your VB6 exe file in the MMM package folder to
make sure that it still runs okay, even though the main system OCX has
been unregistered. You should find that the exe file in the MMM
package folder works fine but that any other VB6 project (or compiled
exe) which uses the RichTextBox control fails to work (because you
have unregistered richtx32.ocx).

4. Now you need to modify the compiled exe file that MMM created in
the MMM package folder so as to enable you to move the MMM package OCX
file (richtx32.ocx in this example) out of the main MMM package folder
and into a sub folder in such a way that the compiled exe still works.
To do this, start a new VB project and run the following code on the
compiled exe file that MMM created for you, the one in which it
embedded the manifest. Change the hard coded path in the Open
statement in the following code accordingly and change the s1 and s2
strings to whatever OCX you have used (use the same code for all other
OCXs you have used in the project). The string s1 must be exactly as
shown, except that it should contain the name of the OCX you have used
yourself (in this example it is the richtx32.ocx). The string s2 is
exactly the same as the string s1, except that the first four
characters of the ocx name are replaced by OCX\ (as in the example):

Dim s1 As String, s2 As String, s3 As String
Open "c:\myproject\MMMPack\myproject.exe" For Binary As 1
s1 = Space$(LOF(1))
Get 1, 1, s1
s2 = "<file name=""richtx32.ocx"">"
s3 = "<file name=""OCX\tx32.ocx"">"
s1 = Replace(s1, s2, s3, vbTextCompare)
Put 1, 1, s1
Close 1

5. When you have run the above code, again double click your VB6 exe
file in the MMM package folder. This time you should find that it
fails to run (because it no longer contains the correct reference in
the embedded manifest file which the above code has just edited).

6. Now create a new folder in your MMM Package folder and rename the
new folder OCX and manually move the ocx file (richtx32.ocx in this
specific example) out of the MMM Package folder and into the new OCX
folder that you just created. Then manually rename the ocx file by
removing the first four characters of its name (for example, rename
richtx32.ocx to tx32.ocx).

9. Double click your exe file in the MMM package folder. You should
find that it now runs okay again, even though the (renamed) OCX file
is now in the sub folder rather than the main folder.

10. Once you have finished and have checked that it works okay then
you use a DOS box to manually re register the main system OCX (again
making sure that you run the DOS box as Admin in Vista). For this
specific example you would enter the following into the DOS box:

regsvr32 c:\windows\system32\richtx32.ocx

As I've said, this is really just a kludge at this stage, but it does
seem to work okay.

Mike

On 1 Nov, 17:44, "Mojo" <ple...@dont.spam.com> wrote:

> Hi Mike. Many, many thanks for this. I also followed this
> same kind of path in my testings, but when it came to
> mod-ing the embeded manifest I created kludge #2 ! :0)
> I created the manifest file 'unembeded', edited it to the
> sub-folder path and modded bits of text to make the entire
> xml 640 bytes in size . . . . . I then used a resource
> editor (XN resourced editor if this makes a diff!!!) and
> edited the Manifest resource part so that the text followed
> the same character by character format of my text block.

Actually that seems an even better idea, Mojo, and is easier than
writing VB code to modify the resource. It just never even entered my
head to use a ready made resource editor :O)

I've just used that method to check it out and it seems to work fine,
regardless of whether the edited resource is the same size as the
original or not, so there seems to be no need to worry about the size.

All I did was to run a standard VB project (using a RichTextBox for
test purposes) through MMM in the usual way, requesting MMM to embed
the manifest into the exe file. I did not then bother about editing
the name of the richtx32.ocx file, but simply ran the resultant exe
through the XN resource editor that you mentioned and edited the part
"richtx32.ocx" so that it read "support\richtx32.ocx". I then created
a subfolder called Support and move the richtx32.ocx file into it.
Everything worked fine. Have you tried that method?

Mike

Hi Mike

Yep tried it and up to now (fingers firmly crossed!) it seems to work fine.

I've tested it on 2 x XP machines (one with the file in the system folder
and one that doesn't have the file at all) and both do the biz at the mo.
My colleague is going to test it out on Vista tomorrow (as I won't touch the
thing :0) and hopefully we are in happy land.

I can't thank you enough for your time and patience on this matter.

All the best.

Rgds

Mojo

"Mike Williams" <gagamomo@yahoo.co.uk> wrote in message
news:bd309931-838e-471e-bf8a-ecb82056a6f8@o10g2000yqa.googlegroups.com...
On 1 Nov, 17:44, "Mojo" <ple...@dont.spam.com> wrote:

> Hi Mike. Many, many thanks for this. I also followed this
> same kind of path in my testings, but when it came to
> mod-ing the embeded manifest I created kludge #2 ! :0)
> I created the manifest file 'unembeded', edited it to the
> sub-folder path and modded bits of text to make the entire
> xml 640 bytes in size . . . . . I then used a resource
> editor (XN resourced editor if this makes a diff!!!) and
> edited the Manifest resource part so that the text followed
> the same character by character format of my text block.

Actually that seems an even better idea, Mojo, and is easier than
writing VB code to modify the resource. It just never even entered my
head to use a ready made resource editor :O)

I've just used that method to check it out and it seems to work fine,
regardless of whether the edited resource is the same size as the
original or not, so there seems to be no need to worry about the size.

All I did was to run a standard VB project (using a RichTextBox for
test purposes) through MMM in the usual way, requesting MMM to embed
the manifest into the exe file. I did not then bother about editing
the name of the richtx32.ocx file, but simply ran the resultant exe
through the XN resource editor that you mentioned and edited the part
"richtx32.ocx" so that it read "support\richtx32.ocx". I then created
a subfolder called Support and move the richtx32.ocx file into it.
Everything worked fine. Have you tried that method?

Mike

On 01/11/2009 12:58, Mojo wrote:
> "Dee Earley"<dee.earley@icode.co.uk> wrote in message
> news:4aeaac24$0$350$7b0f0fd3@reader.news.newnet.co .uk...
>> On 29/10/2009 18:48, Mojo wrote:
>>> My query is therefore, can I put the MSFLXGRD.OCX in my portable folder
>>> and
>>> simply call/use it within my app without having to put it in the system
>>> folder and register it????
>>
>> Yes.
>
> Err... thanks Dee
>
> Is that it?

Yep

--
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team

iCode Systems

On 2 Nov, 01:59, "Mojo" <ple...@dont.spam.com> wrote:

> Yep tried it and up to now (fingers firmly crossed!) it
> seems to work fine. I've tested it on 2 x XP machines
> (one with the file in the system folder and one that doesn't
> have the file at all) and both do the biz at the mo. My
> colleague is going to test it out on Vista tomorrow (as
> I won't touch the thing :0) and hopefully we are in happy land.

Actually I've been doing all my own testing on Vista, and it works
fine. By the way, regarding the editing of the dependency file to
include the desired support folder name (for your OCX files) I've just
had another look at MMM (which I don't use much myself, as I mentioned
earlier) and I notice that there is an option to specify the name of
the desired dependencies folder on the last page of the wizard, so if
you type the name "support" in there then MMM will create the
appropriate manifest for you, so the manifest does not need to be
later edited.

Mike

On 2 Nov, 13:37, Dee Earley <dee.ear...@icode.co.uk> wrote:
> On 01/11/2009 12:58, Mojo wrote:
>
> > "Dee Earley"<dee.ear...@icode.co.uk> *wrote in message
> >news:4aeaac24$0$350$7b0f0fd3@reader.news.newnet.c o.uk...
> >> On 29/10/2009 18:48, Mojo wrote:
> >>> My query is therefore, can I put the MSFLXGRD.OCX in my portable folder
> >>> and
> >>> simply call/use it within my app without having to put it in the system
> >>> folder and register it????
>
> >> Yes.
>
> > Err... thanks Dee
>
> > Is that it?
>
> Yep

That's not the way it works, Dee. Simply placing the MSFLXGRD.OCX file
in the same folder as your compiled VB6 exe file will not work when
you run the compiled exe on a target machine that does not already
have the OCX installed and registered. If you do as you suggest then
the MSFLXGRD file in the folder will simply be ignored, and the
compiled exe will work ONLY on those machines on which the
MSFLXGRD.OCX file is already registered. The idea is to have the
compiled VB6 exe file work on all machines, even on machines which do
not have the MSFLXGRD file registered. To do that you need to either
use an installation package that runs on the target machine or place
code in your app to provide and register the OCX on the target
machine, or alternatively (in the case of WinXP and later) create
and / or embed a manifest file as we have been discussing.

Mike