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 derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Networking Problem

Status
Not open for further replies.

webpager

Programmer
Joined
Mar 27, 2001
Messages
166
Location
GB
Hi all
I have an app. operating over a network of 2 machines.
The app. has been running without problems while both machines use WIN98. My client recently installed WINXP on the client machine and has created a few problems. All of the problems are fixed except for 1. This involces running a third party POSTCODE finder by AFD software. The POSTCODE program works OK on the host machine but the remote machine was searching for DDEREG.EXE. I have added the file to the WINDOWS SYSTEM32 directory and now is unable to load a ".DLL" file associated with the POSTCODE software. The ".DLL" is on both of the machines.

I am now wondering if the problem lies with a mismatch between WIN98 and WINXP. The info I have on DDEREG.EXE suggests it is a gateway between 16BIT and 32BIT operations.

Does anyone have any experience of this problem.
If it cannot be resolved - I will have to install WIN98 back on to the remote machine but thought I`d do a bit of experimenting first.

Thanks in anticipation
Keith
 
Hi
I suggest you copy DDEREG.EXE in the application directory and also the associated .DLL files in the application directory.

While the information from you is not enough and I havent worked with AFD software, it appears, that must be a resonably earlier version (since DDE is used) and it may also have association with FoxTools.FLL. SO i suggest, you include the FoxTools.fll also in your application directoy.

SInce my suggestion is a simple attempt, I would suggest you to try this way :-)

Good Luck :-) ramani :-)
(Subramanian.G),FoxAcc, ramani_g@yahoo.com
 
HI
Have a look into this Link and search for DDEREG.EXE

**************** Quote *********
Visual FoxPro Runtime and FoxTools
Rick Strahl

Recently when distributing a Visual FoxPro application that required Foxtools.fll for accessing some 16 bit Windows API functions was causing me some major headaches. An undocumented omission in the Visual FoxPro Setup Wizard fails to install a vital file required to use Foxtools when running a distributed EXE file. Make sure you explicitly copy DDEREG.EXE into your application directory and include it in the list of files to distribute! Without this file, every call to RegFn() will fail - a dialog box without an explicit caption will come up prompting for a file name.

For those wondering: Using Foxtools for 16 bit API access requires a DDE service to provide the 32 to 16 bit thunking layer. As you might expect this causes a bit of overhead both in processing time and system resources used. Therefore, whenever possible use the new DECLARE-DLL syntax to call API functions in the Win32 API directly.

A related trap: Visual FoxPro's Setup Wizard installs the ESL runtime file into the \WINDOWS\SYSTEM directory by default. This has a critical effect on what the HOME() and SYS(2004) functions return. These functions are frequently used to determine where the application was started from and to load library and support files from. With the ESL in \WINDOWS\SYSTEM both HOME() and SYS(2004) return that directory, rather than the much more useful EXE file startup directory.

You can explicitly include the ESL file in the application directory and then delete the remove the default ESL entry the Setup Wizard puts into the list of distributable files in the Setup Wizard. Alternately, you can ignore HOME() and SYS(2004) altogether and rely on an application variable or propery to store the application directory for you:THIS.AppPath=LEFT(SYS(16),RAT("\",SYS(16))

*************************************unqote.......
:-) ramani :-)
(Subramanian.G),FoxAcc, ramani_g@yahoo.com
 
Thanks Ramani
I too did a search on Google for DDEREG.EXE to see what it was and read the article you suggested.
Initially the app. asked for DDEREG.EXE in WINDOWS\SYSTEM32 so I put it in there. That stopped it asking for the file but came up with a message - "Cannot load POSTCODE.DLL".
I have created a drive (Z:) on the host machine using the SUBST command and the whole app. worked fine under WIN98.
I have contacted AFD software but have yet to receive a reply. Think I`ll phone the tech help and see if they have any updated progs available.
I must admit, I am tempted to revert back to WIN98 and leave the development of DDEREG.EXE in WINXP to people with time to play.
Thanks for the response - I do appreciate it but why do we have to re-invent the wheel every time Microsoft upgrades something.
Keith
 
Hi
... but why do we have to re-invent the wheel every time Microsoft upgrades something.

That is million dollar puzzle... spinning may be billion for Bill. But dont we want to drive faster with the new wheel invented?. But we do have to face some crashes in the process !

If every one is using the old system and continue to use that, we will be out of job today. Just the lighter side.. I want to be an optimist. :-)
ramani :-)
(Subramanian.G),FoxAcc, ramani_g@yahoo.com
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top