Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community

At 18 FEB 2002 07:30:27PM Dave Ballance wrote:

Obviously, I am missing something. When I try to run OIPI now that I upgraded I'm getting an error:

ENG805: Set_printer line 1 function getwindowtextlength does not exist in dynamic length library USER.DLL.

This will certainly prove my ignorance about calling DLLs from OI (and maybe other stuff too) but that's okay. What's wrong here?

Dave


At 18 FEB 2002 07:46PM Donald Bakke wrote:

Dave,

OI32 can only run OIPI32. Hence, you need to use the START32 and STOP32 commands to invoke it. Otherwise, you are calling old 16-bit code which relies on 16-bit WinAPI functions - and these give you the error you reported.

[email protected]

SRP Computer Solutions, Inc.


At 18 FEB 2002 07:48PM Oystein Reigem wrote:

Dave,

Have you done a search for getwindowtextlength? (You might even find a posting of your own.)

- Oystein -


At 18 FEB 2002 08:38PM Dave Ballance wrote:

Don:

I already tried that as well as re-installing OIPI. Also, tried running the declare_fcns too.

Dave


At 18 FEB 2002 09:22PM Donald Bakke wrote:

Dave,

What DLL stub did you run the DECLARE_FCNS routine against? Also, did you ever run this against the local application versus SYSPROG? This would but a local version of the WinAPI function in this application which won't get automatically upgraded with OI32.

[email protected]

SRP Computer Solutions, Inc.


At 19 FEB 2002 12:30AM Graeme Hall wrote:

I too am getting this error from OIPI - which was, prior to the upgrade to OI32, running fine with START32 and STOP32 calls in place. The interesting thing is that OI is attempting to load GetWindowTextLength from USER.DLL even after running DECLARE_FCNS on DLL_OIPI_USER32. I tried re-declaring a call to a test DLL I had that used to use a 16-bit call, but was re-prototyped using a different DLL file, but still with the same entry point. Although it claims to run OK, calls to the function result an this same error - unable to find function in old-DLL filename. Do you need to un-declare old functions first? Another new entry point in the same new DLL found the file OK - just old ones that fail.

I've tried DECLARE_FCNS from my usual System Admin level user as well as SYSPROG to no avail.

Graeme


At 19 FEB 2002 11:59AM Donald Bakke wrote:

Graeme,

The only reasons I can think of why OI is trying to load GetWindowTextLength from USER.EXE (rather than USER32.EXE) are:

1. Running DECLARE_FCNS is failing either because the original records won't allow themselves to be overwritten or the prototypes are incorrect (easily confirmed by opening the DLL_USER32 record from SYSPROCS.)

2. Your local application some how has its own GetWindowTextLength - i.e. $GETWINDOWTEXTLENGTH*APPNAME. This version will always be referenced by OI when called within that application. Do a Ctrl-R from the System Editor and examine SYSOBJ for multiple entries. If you find one for a specific application then I suggest deleting it so OI will use the version in SYSPROG (which should be correct.)

If all else fails, manually delete all the API functions in SYSOBJ and then re-run the DECLARE_FCNS routine against the 32-bit DLL records.

[email protected]

SRP Computer Solutions, Inc.


At 19 FEB 2002 12:22PM Richard Richter wrote:

For whatever it's worth, I'm having the exact same problem. This OIPI program was running perfectly under 3.7.5. I am using NT4.

I tried recompiling the program and upgrading to OIPI 4.1. Neither helped.

Any help would be greatly appreciated.

Richard Richter


At 19 FEB 2002 02:23PM jhenry wrote:

Don,

I'm having the same problem with the OIPI falling over after the upgrade. As you suggested, I checked the SYSPROCS table and found DLL_USER*MRP indicating that I had at some time prototyped using a specific application rather than SYSPROG. How do you 'UN_DECLARE_FCNS' ?

TIA

John Henry


At 19 FEB 2002 03:27PM Mike Ruane wrote:

John-

Look at all the function Calls in the dll.

You need to delete them one by one-

eg

run delete_row 'sysobj','$GetWindowTectLength*MRP'

but use the real name of the row in SYSOBJ

Mike


At 19 FEB 2002 06:22PM Dave Ballance wrote:

When I looked in the sysobj I had no App-Specific objects. So, I logged into SYSPROG and deleted all the routines listed in DLL_OIPI_USER:

RUN DELETE_ROW 'SYSOBJ','$GetWindowTextLength'

RUN DELETE_ROW 'SYSOBJ','$GetWindowText'

etc.

Then I ran the DECLARE_FCNS for the 32-bit only while still logged into SYSPROG.

Now, I start32 and it works fine.

Dave


At 19 FEB 2002 11:22PM S Botes wrote:

I have worked through this thread and tried all of the suggestions. I am running START32 in the window createe, verifying that it starts okay. When I try to execute and printing function either S/List or pure OIPI I get the following error.

ENG0805i Set_Printer line 192 Function GetNextWindow does not exist in Dynamic Link Library User32.

I am stumped. I have tried manually deleting all of the entries in both DLL_OIPI_USER and DLL_OIPI_USER32. I then ran Declare_FCN DLL_OIPI_USER32 all seems fine but the same problem exists.

Any ideas?


At 20 FEB 2002 03:19AM Graeme Hall wrote:

Me too, same place!

I don't know where GetNextWindow is cos I can't find it in any 32-bit DLL on Win2000 or 98. Only reference seems to be in USER.EXE.


At 20 FEB 2002 05:32AM Pat McNerthney wrote:

In Win32 there is not a GetNextWindow, in the Windows C header files this is defined as:

#define GetNextWindow(hWnd, wCmd) GetWindow(hWnd, wCmd)

In other words, it is really a call to GetWindow with the same parameters.

Pat


At 20 FEB 2002 11:50AM S Botes wrote:

I am having the problem invoking SET_PRINTER, the OIPI, call. So I am reasonable sure that my problem is related to the update and the previous discussion on this link. I just can't find what is causing the problem. Any direction would be appreciated. Thanks


At 20 FEB 2002 12:20PM jhenry wrote:

In the SYSPROG account, SYSOBJ table, I removed the following from an updated (to 4.01) test system and the OIPI functions started working.

$WINEXEC*(null appname)

$WINEXEC*appname

$GETMODULEUSAGE*appname

$GETNEXTWINDOW*appname

$GETWINDOWTEXT*appname

$GETWINDOWTEXTLENGTH*appname

$REGISTERWINDOWMESSAGE*(null appname)

$REGISTERWINDOWMESSAGE*appname

IF you look at 'DLL_OIPI_KERNEL' and 'DLL_OIPI_USER' in the SYSPROCS table, you'll see the prototype information that DECLARE_FCNS used to put these items in the SYSOBJ table. Apparently I need to pay more attention to which application I'm in when installing stuff!


At 20 FEB 2002 01:45PM Mike Ruane wrote:

Dave-

Glad to hear it.

When I get back in the office (I'm at the International Spectrum show in San Diego) I'll take a look at the upgrade process, and see if we should delete the existing pieces before we install the new ones.

Thanks-

Mike


At 20 FEB 2002 05:49PM S Botes wrote:

Alas no joy….. Just went through all of JHenry's suggestions and also opened DLL_OIPI_USER, DLL_OIPI_USER32, DLL_OIPI_KERNEL, DLL_OIPI_KERNEL32 and deleted all of the corresponding entries in SYSOBJ. I was careful to also make sure that I got all of those with a following * and a following application. Then I went back and Declared DLL_OIPI_KERNEL32 and DLL_OIPI_USER32 while logged into SYSPROG. I did not declare the other two, DLL_OIPI_USER and DLL_OIPI_KERNEL. I am running START32 and have confirmed that it is successful. I still break to the DEBUGGER with the same error

ENG0805i Set_Printer line 192 Function GetNextWindow does not exist in Dynamic Link Library User32

I am stumped. Where have I not looked???


At 20 FEB 2002 05:54PM Dimitri Mandelis wrote:

Same problem here running OIPI - deleted suggested entries from

sysobj – no change

any ideas?

Dimitri


At 20 FEB 2002 06:35PM Graeme Hall wrote:

Pat

Thanks for that - spot on!

To reiterate… after logging in as SYSPROG and EXECing

RUN DELETE_ROW "SYSOBJ", "$GETNEXTWINDOW"

to clear out the old entry (and UPPERCASE seems to be important), adding a SYSPROCS record with

USER32

HANDLE STDCALL GetWindow(HANDLE,UINT) AS GetNextWindow

and then running DECLARE_FCNS on this, OIPI went without a hitch!!

Graeme


At 21 FEB 2002 11:35AM B Stevens wrote:

I got this error also (GetNextWindow) and the same data is in sysobj…

What have we been doing wrong…makes the upgrade a bit of a pain now.

Barry


At 21 FEB 2002 12:31PM B Stevens wrote:

You need to change your DLL_OIPI_USER32 to

USER32

UINT STDCALL RegisterWindowMessageA(LPCHAR) AS REGISTERWINDOWMESSAGE

HANDLE STDCALL GetWindow(HANDLE,UINT) AS GetNextWindow

INT STDCALL GetWindowTextLengthA(HANDLE) AS GETWINDOWTEXTLENGTH

INT STDCALL GetWindowTextA(HANDLE,LPCHAR,INT) AS GETWINDOWTEXT

and exec

RUN DECLARE_FCNS "DLL_OIPI_USER32"

ATTN: Mike (Revelation)

Can we get this changed in the OIPI32 install

Barry


At 21 FEB 2002 12:31PM jhenry wrote:

I tried the upgrade against a fresh copy of OI 3.75 again and had the same problems re-appear. Can't find GETWINDOWTEXTLENGTH… I checked the SYSOBJ and found that I had $GETWINDOWTEXTLENGTH*appname items again and I removed those.

At this point, using the START32 and STOP32 calls from the application startup screen, the printing worked. Without START32/STOP32, the error message returned. Basically, OIPI32 works but OIPI doesn't.


At 21 FEB 2002 12:38PM B Stevens wrote:

WAIT

Would this still work on a OI 3.7.5 version????


At 21 FEB 2002 12:48PM B Stevens wrote:

This is now totally confusing…

Appears we need a different OIPI32 install for OI V4.01 and OI 3.7.5

I wonder if the OIPI32 install for OI V4.01 could be made to delete the all the OIPI32 $sysobjs containing a "*".

Because someone installing months down the track (including devs in this) could not know/forget about this.

Or am I just an old man barking up the wrong tree

Barry


At 22 FEB 2002 05:43AM Richard Bright wrote:

Barry,

I'm uncertain that you have the line correct -

You need to change your DLL_OIPI_USER32 to

USER32

HANDLE STDCALL GetWindow(HANDLE,UINT) AS GetNextWindow

* Note that in User32 we have HANDLE STDCALL GetWindow(HANDLE,UINT) *

'Cause, I could be wrong . (I note that your proposed construct is in my DLL_OIPI_USER32 - but I havnt tested - will do asap.

I pesume that the upgrade recast all DLLs as it could and left the remains for us to mop up. Not un - reasonable. However nice to understand what / how to to that mop-up.

Richard Bright

[email protected]

View this thread on the Works forum...

  • third_party_content/community/commentary/forums_works/adce0e2899fff72b88256b650002c9d9.txt
  • Last modified: 2023/12/30 11:57
  • by 127.0.0.1