DLL 1

[ariftheruvath]

I ve built a Single Threaded DLL with VFP.9.0

project = mydll
programme name= mydll

DEFINE CLASS msgtest AS SESSION OLEPUBLIC
FUNCTION msg
WAIT "sdfsf"
ENDFUNC

ENDDEFINE

****************

and tested :-
x = CREATEOBJECT("mydll.msgtest")
x.msg()

returns an error msg ' OLE Idispatch exception code 2031....error in line 3 user-interface operation not allowed this time.2031'

im working around making DLL with vfp 9.
the above code was just for a trial.

 

[Olaf Doschke]

Well, a DLL can't do visual things. WAIT creates a visual message, so that's not allowed in a DLL.

Bye, Olaf.

 

[ariftheruvath]

thank olaf.
i built a multi threaded VFP DLL.
and when i tried :-
x = CREATEOBJECT("mydll.msgtest")

i get an error msg. 'Resource File version mismatch'

 

[Olaf Doschke]

On the same computer as you created the DLL?

The DLL neeeds runtimes, like an EXE does, and these need to be the same version as you used to compile. There really would be an awkward situation on your development machine, if you'd not have the same resource DLLs (vfp9enu.dll for example is one of them) which match your VFP installation. If you're not english it can happen, that one of those DLLs is missing, defect or the wrong versiion, because the VFP IDE is english only.

For a multithreaded DLL you need VFP9t.dll aside of all other runtime files.

Also see

http://fox.wikis.com/wc.dll?Wiki~VFP9RuntimeFiles

Bye, Olaf.

 

[Olaf Doschke]

There's one detail I forgot to mention: At design, wehen using the ID you're using the vfp9enu.dll, at runtime, when running a DLL or EXE instead the vfp9renu.dll is used, so that's two DLLs even for the same english language, and the vfp9renu.dll cna be broken. The OS main language you set determines, which vfp9rXXX.dll is used, there are many languages from german (deu) french (fra), korean (kor), russion (rus) and more.

You need the right version in regard of whatever exact VFP version you used to compile. Tehre are for example 5 different versions of DLLs for the SP2 alone, there was the original SP2 9.0.0.5721, then there was 9.0.0.5815 with merely a fix in the VFP IDE splash screen graphic, still yet the resource DLLs for that version differ, though it's also SP2, then there are three hotfixes, 9.0.0.6303, 9.0.0.6602 and 9.0.0.7423.

You have to be precise here. ? Version(4) will show you the exact vcersion you have installed as DLL, if the versions of runtime files installed in common files/ms shared/vfp folder don't match that, someone may have wrongly installed some hotfix not following readme instructions fully.

You have to be precise here.

Bye, Olaf.

 

[TamarGranor]

There really would be an awkward situation on your development machine, if you'd not have the same resource DLLs (vfp9enu.dll for example is one of them) which match your VFP installation.

Happened to me recently. I had to install a client's EXE and it was using earlier runtimes. It was a PITA to clean up afterward.

Tamar

 

[Olaf Doschke]

What happened to me recently is a totally messed up notebook with two different version DLLs mixed in the ms shared/VFP system folder.

As that wasn't the only messed notebook for that client I had to create a setup which would clean up, uninstall a runtime installer package and install the correct version runtimes including msvcp71.dll for vfpcompression.fll. I learned to use msiexec for that matter, also for uninstalling, and found a tool called msm2msi by which I could turn the merge modules coming with VFP into msi setups.

All tht would not have been needed if the runtimes I distributed within the app folder weren't deleted, because then whatever mess was installed would not have been used anyway.

There's one most important thing to know:
In an EXE or DLL you have a stub routine which loads the main vfp runtime, in case of VFP9 either vfp9r.dll or vfp9t.dll as runtime for a multithreaded VFP COM DLL. The bad thing, inside the EXE or DLL you find VisualFoxproRuntime.9, not the more specific version number. But the opject code is for a certain version. What works most of the time is an EXE compiled in an earlier VFP9 version IDE can be run with the latest hotfix VFP9r.dll wothout a recmopilation. Because many opcode of object code don't change, what is fixed is the code in the runtime, and so you cn profit of bugfixes in runtimes without EXE recompilation and redistribution. But, and that is a big downer for this, I made very bad experences about this with SQLBUFFERING mode.

And what relates back to the original error, if the vfp9r.dll or vfp9t.dll is loaded by the EXE, DLL or MT DLL, then that runtime DLL loads the vfp9renu.dll (or other language) resource DLL and only accepts the exact same version a itself has, otherwise you get that resource file version mismatch. You have to be an obsessed perfectionist about this, if you want your final EXE or DLL o work on the target machine.

If you install one of the hotfixes, they automatically fix the main vfp9.exe of the IDE in the Home() folder, but other files like merge modules and runtime DLLs for the Ms Sahred system folder are merely extrated and you are instructed to move these files into system. If you don't follow these instructions you can easily run into this situation with a version mix in Home() and system folders for runtimes and merge modules. Then later creating setups on that wrong basis merge modules leads to further problems, only your customer will detect.

In my case that was only revealed after an update. Indeed an applilcation by me worked with a mix of 9.0.0.7423 vfp9r.dll and 9.0.0.5721 vfp9renu.dll(!) Which indeed shouldn't work according to what I said, after an update,which included all version 9.0.0.5815 version DLLs, just the vfp9renu.dll was upgraded to that version, while vfp9r.dll still remained as version 9.0.0.7423, and that, and only that lead to the version mismatch. So the update was indeed correctly packaged, it just was only upgradeing files newer and so that caused a problem.

Then also end users come to forums reporting their foxpro application doesn't work and put in some DLLs they are pointed to the fox wiki about runtime and don't understand half of it.

Ok, rant mode off.

In Windows Explorer you can add the file version attribute as a column of a detail/list display of files. That really is helpful to get an overview on what you have and if that all is the same version or not, and then you can fix that.

Bye, Olaf.

 

[ariftheruvath]

Thank you sooooo much Olaf. (* * * * *)
it was a great information for me ..not only related to DLL but it solved my FOXCHARTS issues as well.

thanks a lot

..Arif..

 

[Olaf Doschke]

I don't know how that solved what foxcharts issue, but fine.

Bye, Olaf.