hainansyndrome
asked on
foxpro dll breaking when region settings are changed
I have a foxpro dll that that accepts 2 string Parameters.
I am calling it from a VB6 dll
when I compile the foxpro dll under US region settings and run my application everything is fine.
However when i change region settings to Canada i get the following errors
Class does not support Automation or does not support expected interface GetFilez/Line 5
If i recompile while set to Canadian settings it all works fine but when I switch to USA region Settings same error as above
I am calling it from a VB6 dll
when I compile the foxpro dll under US region settings and run my application everything is fine.
However when i change region settings to Canada i get the following errors
Class does not support Automation or does not support expected interface GetFilez/Line 5
If i recompile while set to Canadian settings it all works fine but when I switch to USA region Settings same error as above
vb6 coded
4 Dim oNMS As New clsNMS.COPYFILES
5 bCopyFiles = oNMS.getfilez(Trim(sPMSPath), Trim(WorkingFolder))
Foxpro Code
DEFINE CLASS COPYFILES AS Custom OLEPUBLIC
FUNCTION GETFILEZ(SDB,SWD)
*SET DELETED ON
*SET EXCLUSIVE OFF
SWORKINGDIR = SWD
SDBDIR = SDB
DECLARE Sleep IN kernel32 INTEGER dwMilliseconds
DO GETFILES
Sleep (5000)
RETURN .T.
End FunctionASKER
I make sure the dll's are not in use.
the thing is it works when I switch my region settings back to the zone that the DLL's were compiled in
on the foxpro dll
i am using VFP 6
I and BULDING COM DLL
I do not have regenerate ComponentIDs checked, so no i dont
the thing is it works when I switch my region settings back to the zone that the DLL's were compiled in
on the foxpro dll
i am using VFP 6
I and BULDING COM DLL
I do not have regenerate ComponentIDs checked, so no i dont
I just don't see how region settings would influence an ole class being automatiable or not, other than it might influence on what you and your VB code sees in the registry. But the registry also isn`t depending on region settings.
The region setting can influence what resource DLL of the runtime is used. I'm not aware of a canadian version, default always is the enu dll vfp6renu.dll. There is no canadian english or british english resource file.
Bye, Olaf.
The region setting can influence what resource DLL of the runtime is used. I'm not aware of a canadian version, default always is the enu dll vfp6renu.dll. There is no canadian english or british english resource file.
Bye, Olaf.
ASKER
i dont think the vb6 code plays in anywhere
it gets to the same point reguardless of compile or region settings
5 bCopyFiles = oNMS.getfilez(Trim(sPMSPat
it is always when calling into the foxpro dll that the error occurs
it gets to the same point reguardless of compile or region settings
5 bCopyFiles = oNMS.getfilez(Trim(sPMSPat
it is always when calling into the foxpro dll that the error occurs
I didn't say it's the VB code. It's neither a VB code nor a Fox code issue. If the class or it's interface isn't found it would rather be a OS issue. Or registry. And the component IDs are what would play a role there.
regional settings only have influence of what language resource runtime DLL of foxpro is used. But even if one is missing the deafult enu dll would be used.
I daon't know what else would play a role.
Maybe time to analize the problem via tools. Process monitor could say more about what's going on, when the VB code hits the line calling the fox COM object.
Bye, Olaf.
regional settings only have influence of what language resource runtime DLL of foxpro is used. But even if one is missing the deafult enu dll would be used.
I daon't know what else would play a role.
Maybe time to analize the problem via tools. Process monitor could say more about what's going on, when the VB code hits the line calling the fox COM object.
Bye, Olaf.
ASKER
i tried all of that and I cant figure it out
nothing is working
I am even trying other machines to make sure
nothing is working
I am even trying other machines to make sure
Things that "Class does not support Automation or does not support expected interface" mean:
1. "does not support Automation"
Well, obviously wrong, but maybe a registration issue. At least the class is know, otherwise an error would be "class definition not found".
2. "does not support expected interface"
The typelib of an ole class defines an interface, mostly that is: a) what method names and b) what parameterisation
are offered by the ole class.
If it's an issue between expected and real interface, that could be due to changes. But you say you simply change region and not any code, so there is no difference in registered vs real interface.
Again the culprit may again be the registration.
You are doing early binding in VB. What you could try is:
Dim oNMS As Object
oNMS = CreateObject("clsNMS.COPYF
bCopyFiles = oNMS.getfilez(Trim(sPMSPat
Which would be late binding.
Bye, Olaf.
1. "does not support Automation"
Well, obviously wrong, but maybe a registration issue. At least the class is know, otherwise an error would be "class definition not found".
2. "does not support expected interface"
The typelib of an ole class defines an interface, mostly that is: a) what method names and b) what parameterisation
are offered by the ole class.
If it's an issue between expected and real interface, that could be due to changes. But you say you simply change region and not any code, so there is no difference in registered vs real interface.
Again the culprit may again be the registration.
You are doing early binding in VB. What you could try is:
Dim oNMS As Object
oNMS = CreateObject("clsNMS.COPYF
bCopyFiles = oNMS.getfilez(Trim(sPMSPat
Which would be late binding.
Bye, Olaf.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
END or END FUNCTION indeed will not work out, END FUNCTION leads to compile error "unrecognized phrase/keyword".
Indeed ENDFUNC is as optional as is ENDPROC. Foxpro does not need an end delimiter for procedures or functions, the next PROCEDURE or FUNCTION is both end of previous and start of the next procedure/function.
As your code did compile, I thought of it as a posting error, you can't compile that without getting an error.
Besides, revisiting and reinspecting your code - Foxpro does only make a difference between FUNCTION and PROCEDURE as stand alone constructs. In a class we talk of methods and foxpro stores all methods as PROCEDURE, not as FUNCTION (take any visual class in the class browser and use the "viewcode" button and you'll see, dito if you open a vcx as table and look into the code memo) , but indeed in a prg class definition with DEFINE CLASS FUNCTIONs also work out as methods.
Bye, Olaf.
Indeed ENDFUNC is as optional as is ENDPROC. Foxpro does not need an end delimiter for procedures or functions, the next PROCEDURE or FUNCTION is both end of previous and start of the next procedure/function.
As your code did compile, I thought of it as a posting error, you can't compile that without getting an error.
Besides, revisiting and reinspecting your code - Foxpro does only make a difference between FUNCTION and PROCEDURE as stand alone constructs. In a class we talk of methods and foxpro stores all methods as PROCEDURE, not as FUNCTION (take any visual class in the class browser and use the "viewcode" button and you'll see, dito if you open a vcx as table and look into the code memo) , but indeed in a prg class definition with DEFINE CLASS FUNCTIONs also work out as methods.
Bye, Olaf.
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
Do you compile in VFP with regenerting Component IDs? Then you need to reregister OLE classes and VB may have the old ones still in "mind". Eg in VBA you need to add references to OLE classes and those References get invalid, if the component IDs change.
Region dependant registration doesn't make any sense, I`ve no idea where this could play a roll.
Try to turn off regenerating copmponent IDs, then compile once again, add refereneces to VB and then see if recompilation renders the dll useless again or not.
Another thing: You can't recompile and replace a DLL, as long as it's in use. That might also play a role in rendering the foxpro DLL useless and the observation of regional setting was perhaps just coincidential.
Bye, Olaf.