Ever since upgrading to OI 7.0 I get the following error when going into my main app. in development mode. I do not however get this message when logging into SYSPROG or EXAMPLES.

The message is

ENG0805: REV_BGND_UPDATE, line 1. Function GETTICKCOUNT does not exist in dynamic link library USER.DLL.

If I log in runtime mode and launch the app. I get the following error message with the debugger open with the MSG program line 943.

ENG0805: MSG, line 943. Function GETSYSTEMMETRICS does not exist in dynamic link library USER.DLL.

I have checked for the user.dll and the user32.dll and have not found any. ( I am using this on a XP single user )

Any suggestions?

Check for SYSOBJ entries with these names and *APPNAME at the end. The likelihood is you have run DECLARE_FCNS whilst in the account and declared localised versions of these routines. Delete these localised versions and it should revert to using the SYSPROG version.

The Sprezzatura Group

World Leaders in all things RevSoft

Thanks for the reply.

Check for which names ???

REV_BGND_UPDATE*APPNAME?

With a $ prefix or @ prefix?

I checked and do not have those?

Also, if they were there should I use DELETE_ROW ?

$GETTICKCOUNT*APPNAME etc al. Yes use DELETE_ROW.

The Sprezzatura Group

World Leaders in all things RevSoft

Thanks.

That did get rid of those two and now have two more but will just keep deleting.

BTW - what causes this ? I inherited this app. (so I am not sure who compiled those system routines) and we haven't rewritten all of it but we have done OI upgrades before. Why did this jump to 7.0 bring this up?

Normally it is a result of running DECLARE_FCNS in the application you are in. Let's simplify and assume that we're working in 16 bit OI and we want to use a routine called GetTickCount to measure time elapsed. So as this is 16 bit OI we declare it as existing in USER.DLL by making an entry in SYSPROCS called DLL_USER and declaring GETTICKCOUNT. We run DECLARE_FCNS and an entry is made in SYSOBJ called $GETTICKCOUNT that effectively says to RTP27 (the program loader) when I ask for GETTICKCOUNT is's a Windows API call and it is found in USER.DLL.

Then when we're working in APP1 we decide to use another API call called say MyCustomDLLCall which also resides in USER.DLL so we add THIS to DLL_USER and rerun DECLARE_FCNS. This time because we are in APP1 we end up with $GETTICKCOUNT*APP1 and $MYCUSTOMDLLCALL*APP1 in SYSOBJ.

Then along comes OI32 with 32 bit calls and GETTICKCOUNT is now to be found in USER32. So RTI re-prototype GETTICKCOUNT in DLL_USER32 and reship $GETTTICKCOUNT which now points to USER32. Running the program in SYSPROG now works correctly but when you try and run it in APP1 the system, using it's inheritance chaining, looks first for $GETTICKCOUNT*APP1 and FINDS it. Unfortunately it has found the OLD 16 bit version which resides in USER.DLL and as USER.DLL is no longer the same in 32 Bit Windows it can't find it.

So you have a problem.

At Sprezz we get round this by prototyping our API calls in ZZ_WINAPI_USER32_DLL etc and by declaring API entry points as ZZ_WINAPI_GETTICKCOUNT etc. This way our definitions are not overwritten or replaced by Revelation.

The other major downer on the other way of doing it is that when Revelation ship an upgraded version of DLL_USER32 their upgrade proces is not yet sufficiently intelligent to realise that you may have made changes to the definitions in DLL_USER32 (et al and it will blow away your definitions. Our approach protects you from this as well.

The Sprezzatura Group

World Leaders in all things RevSoft

So if there has been no custom API's to user.dll then in theory, to be on the safe side if I look at SYSPROCS*DLL_USER I should effectively RUN DELETE_ROW "SYSOBJ","$callname*MYAPP" on each entry to clean up. Yes?No?

In addition, since I hide the oengine upon lauch of the application using findwindow then showwindow OI reports no showwindow function.

How can I restore this?

BTW - thank you for the explaination, it cleared up alot.

Well to be REALLY safe we'd delete all programs from USER.DLL regardless of whether they belong to you app or not then we'd rerun Declare_Fcns on DLL_USER32.

As for SHOWWINDOW it now belongs in USER32 also - so the above SHOULD cure this.

The Sprezzatura Group

World Leaders in all things RevSoft

Bruce,

I completely agree with Sprezz's recommendations. However, FYI, OI now hides OENGINE for you automatically if it is a runtime engine. OINSIGHT can be hidden by adding a /HI switch to your command line.

[email protected]

SRP Computer Solutions, Inc.

Thanks Don thats good to know.

As for the user.dll.

So should I just delete all of rows in SYSOBJ that are referenced in SYSPROCS?

Should I remove the SYSPROCS*DLL_USER ?

Should I RUN DECLARE_FCNS from SYSPROG only?

Thanks.

As for the user.dll. So should I just delete all of rows in SYSOBJ that are referenced in SYSPROCS?

Well, all rows referenced in DLL_USER (and by extension other 16 bit definitions).

Should I remove the SYSPROCS*DLL_USER ?

That would seem wise.

Should I RUN DECLARE_FCNS from SYSPROG only?

That is a design decision - you may choose to have a localised DLL_USER32 so that you can declare functions as other functions. For normal use we'd say yes.

The Sprezzatura Group

World Leaders in all things RevSoft

Thanks for the reply.

BTW - is this information I should know or I can get from documentation somewhere that I haven't been able to find?

Your reply here…

"Should I remove the SYSPROCS*DLL_USER ?

That would seem wise."

makes me feel like I'm being stupid to ask the question.

No - take it at face value. It would seem wise to remove it but as the I'Ching would suggest "no blame attaches". The fact that these stubs remain in the 32 bit product can only serve to confuse and we would argue for their removal in shipping product. This whole area is one that is fraught with complications and that can easily trap the unwary. We have been caught by similar things with our shipping S/List product several times . OpenInsight's implementation of calling external DLLs is without peer but like any software it can always stand a little improvement!

The Sprezzatura Group

World Leaders in all things RevSoft

View this thread on the forum...