Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Need to use an OCX to another machine 3

Status
Not open for further replies.

medic

Programmer
Jun 14, 2000
459
0
0
US
Hi,

I'm using a an image control in VFP6 which is contained in an OCX file in my computer. My objective is to be able to use that OCX file, in order for my image control to still work, once the application is distributed to a different machine which don't have the OCX file installed.
Could anybody help me solve this?

Medic
 
You have to install the ocx on the other machines. There are various ways to do this and there have been many recent threads on the issue. Try a search on OCX and register.
 
medic

'I'm using a an image control in VFP6 which is contained in an OCX file'

What image control might that be?
FAQ184-2483 - the answer to getting answered.​
Chris [pc2]
 
Thanks for the response fluteplr!

I've searched the threads.
Is there a way to copy/register the OCX automatically, that is, without the need for the user to explicitly copy and register the OCX file?

Medic
 
Chris,

The file is imgedit.ocx from Kodak imaging.

Medic
 
Oh sorry! I might have not clearly said it. What I mean to say in my last question is, is there a way to automate registry of the OCX file via Setup Wizard?

Medic

 
Yes, if you check ActiveX controls in Step #2, and then pick the one(s) you need, it should be automatically registered.

Rick
 
Rick,
The image control I'm concerned with does not appear among the ones listed in Step #2. What could be the reason?

Whatabout if I register the OCX at runtime? Is this programatically possible in VFP6? I checked the FAQ and I found a code that seems to do it but it's reporting an error upon compilation. Any suggestions?

Thanks in advance!

Medic

 
I copied the DCO.OCX to the user's windows/system directory and then use the following line to register it.

run /N regsvr32 DCo_Ocx

The new Installshield for VFP 7 eliminated the need for this bit of code.

hope this helps. Dancing is easy. Now dancing on a floating raft in the middle of an October storm in the middle of the North Atlantic, that is hard.
 
Medic

As the article in the link provided by Jon Hawkins explains, if you are attempting to install the ActiveX control on a Windows XP machine, you are not going to be successful.

What requires you to use imgedit.ocx as opposed to the native VFP image control?
FAQ184-2483 - the answer to getting answered.​
Chris [pc2]
 
Thanks for those inputs guys!

I'm sorry I was not able to give you feedback immediately because I'm off from Sat. to Sun.

Chris, the reason I need the control is I'm using TIFF image format which is not supported by native VFP image control.

Jon, It's a good thing you informed me of that redistribution issue with the Kodak ActiveX controls. That moved me to do an alternative. Now, what I want to do is make a demo CD of my program that would run on machines which don't have the Kodak controls installed in.

For now, I put program codes to check if the ActiveX control is present on the machine. If not, it would then attempt to register (temporarily) the OCX file on the CD, unregistering it afterwards when the user exits the program. I got this idea from a program code posted by Jon (thank you very much, you're a genius) on one of the past threads in here. I am not sure though if this is going to work. I still have to test the program on a computer which don't have the ActiveX installed.

Hope this will make it work. I'll let you know guys.


Medic

 
medic

'I'm using TIFF image format which is not supported by native VFP image control.'

As an alternative and assuming the .tiffs to be single page documents, IrfanView, a freeware image editor would convert from .tiff to .jpg using a command line argument and could be run hidden.
FAQ184-2483 - the answer to getting answered.​
Chris [pc2]
 
Thanks Chris, but my TIFF images are stored in library files, and they always come in this format. My program dynamically and randomly extracts selected TIFF images at runtime, so its not practical to use IrfanView. I'm using FOPEN and FREAD functions to access the images from the library file. A typical library file contains thousands of TIFF images.
Another tough challange going for me is how would I print these images using the native Report Form of VFP. TIFF format is not supported by VFP report forms. What do you think?

Medic
 
medic

'Another tough challange going for me is how would I print these images using the native Report Form of VFP'

You can print these images in an uncontrolled way by using ShellExecute(), and the print parameter.

You would need to ensure that .tiff was associated with a Windows application that could handle .tiffs properly, the obvious being Kodak Imaging, as ShellExecute() will use the Windows associated application to print.

As that is a non starter, you could associate .tiffs with IrfanView or similar and see how that works.

The ideal would be through a VFP report where you could control the format of the image, be it clip, isometric or stretch, but unfortunately and stating the obvious, the image needs to be in a format acceptable to VFP.
FAQ184-2483 - the answer to getting answered.​
Chris [pc2]
 
Thanks Chris! I'll try that out.

Medic
 
Duh, How do you use ShellExecute() Chris? My VFP6 can't seem to recognize it. Is it more flexible compared to the PrintImage method of the Kodak Image Edit control?

Medic
 
medic

Take a look at thread184-424028. Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
 
How about if the application is already loaded and running on the machines. Then you want to add Some Active X stuff. Do you have to register it on all machines or can it be placed in the current directory. I do not want to have to reinstall the whole system again will defeat the purpose.

 
medic

The important parameter, apart from the filename, is lcAction, which determines what action ShellExecute() is to perform.

lnShowWin has a value of 0, which means the application that performs the print operation will be hidden although the print progress dialog might not.

lcFileName = [C:\myapp\test.tiff]

* Retrieve the main VFP window handle (this handle is used by ShellExecute)
DECLARE INTEGER FindWindow IN WIN32API ;
[tab]STRING cNull ,;
[tab]STRING cWinName

DECLARE INTEGER ShellExecute IN shell32.dll ;
[tab]INTEGER hndWin ,;
[tab]STRING lcAction ,;
[tab]STRING lcFileName ,;
[tab]STRING lcParams ,;
[tab]STRING lcDir ,;
[tab]INTEGER lnShowWin

lnResult = ShellExecute(FindWindow( ;
[tab]0,;
[tab]_SCREEN.caption),;
[tab][Print],;
[tab]lcFilename ,;
[tab][] ,;
[tab][] ,;
[tab]0)

FAQ184-2483 - the answer to getting answered.​
Chris [pc2]
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top