OIPI2_PRINTHEADER crash (OpenInsight 32-bit)
At 17 SEP 2020 12:41:20AM Joshua Goddard wrote:
We have a program that sometimes crashes with the following error message :
ENG0016: OIPI2_PRINTHEADER, line 1. Non-numeric data when numeric required. Zero used.
I can't replicate it at will, but it does happen most frequently when the program is run for the first time (after starting OI) and less frequently (if at all) for all subsequent runs of the programs. It has only ever happened on Windows 10, never on Windows 7.
OI:
9.4.1
Windows:
10.0.17763 Build 17763
At 17 SEP 2020 04:53AM Joshua Goddard wrote:
Also, the crash doesn't happen when I add logging or debug statements to the code. So I don't actually know how this function is being called. Is there a way for OI to dump a stack track when this crash occurs?
At 17 SEP 2020 04:59AM Andrew McAuley wrote:
Yes, write a replacement debugger
World leaders in all things RevSoft
At 17 SEP 2020 05:01AM Joshua Goddard wrote:
Thank you, I will have a look.
At 18 SEP 2020 11:04AM Joshua Goddard wrote:
Hi, thanks to the replacement debugger, I was able to get a stack trace. Can someone with access to the code please look at why set_printer2 (Line 1022) would pass a non-numeric value to oipi2_printheader?
Stack trace:
oipi2_printheader (line 1) ←—Revelation
set_printer2( (line 1022) ←—Revelation
set_printer (line 52) ←—Revelation
oryxprn (line 267) ←—TVSN
oryxprn_create_header (line 47) ←—TVSN
roe856 (line 1138) ←—TVSN
woe851_events (line 465) ←—TVSN
At 18 SEP 2020 11:06AM Joshua Goddard wrote:
Hi, thanks to the replacement debugger, I was able to get a stack trace. Can someone with access to the code please look at why set_printer2 (Line 1022) would pass a non-numeric value to oipi2_printheader?
Stack trace:
oipi2_printheader (line 1) ←—Revelation
set_printer2( (line 1022) ←—Revelation
set_printer (line 52) ←—Revelation
oryxprn (line 267) ←—TVSN
oryxprn_create_header (line 47) ←—TVSN
roe856 (line 1138) ←—TVSN
woe851_events (line 465) ←—TVSN
At 21 SEP 2020 11:40PM Joshua Goddard wrote:
Hi,
Could someone please tell me what is passed to oipi2_printheader in set_printer2 on line 1022.
Thanks
At 22 SEP 2020 02:42AM Andrew McAuley wrote:
I don't have source access but the routine takes three parameters, Method, sHead and Flag. It seems highly unlikely that any of these will be required to be numeric so that might be a red herring. A break on line 1 simply means that the routine was compiled without linemarks so the issue could be anywhere in the program.
You don't have a European locale set where a print driver is returning 1.234,56 instead of 1,234.45 do you? If you change printer drivers does it still fail?
World leaders in all things RevSoft
At 22 SEP 2020 04:07AM Joshua Goddard wrote:
Hi,
that's interesting. I will have a look.
At 22 SEP 2020 06:42AM Joshua Goddard wrote:
How do you know what the locale is? I have opened print management in Windows, and I can see a bunch of info about drivers, but nothing about locale.
At 22 SEP 2020 06:49AM Andrew McAuley wrote:
It's Windows locale - so say you've set the keyboard to Dutch and the formatting to English.
For extreme trouble shooting you might want to look at Process Monitor, combining this with engine logs and LH logs is sometimes the only way to track this stuff unless Rev provide you with a debug version of the program.
World leaders in all things RevSoft
At 22 SEP 2020 07:59PM Joshua Goddard wrote:
I found the locale settings. And they look find. I will try the process monitor again. When I last tried it, I couldn't get the crash to occur. But I only tried a few times. I will try more…
Thanks
At 23 SEP 2020 08:15PM Joshua Goddard wrote:
Below is the output of the debugger_dump function in SYSPROG:
I am guessing that the bad variable would be assigned and a string. There are a few of those.
Maybe this is wrong: 598.580596923827.VSPRINTER2.OLE_OIPI
========================================================
_local_1|<string>|INFO
_local_2|<string>|TWIPS_TO_UNITS
_local_3|<integer>|0
_local_4|<unassigned>|
_local_5|<string>|
_local_6|<integer>|1
_local_7|<integer>|0
_local_8|<string>|
_local_9|<string>|598.580596923827
_local_10|<string>|VSPRINTER2
_local_11|<string>|VSPRINTER2.OLE_OIPI
_local_12|<string>|598.580596923827.VSPRINTER2.OLE_OIPI
_local_13|<string>|VSPRINTER.VSPDF
_local_14|<string>|VSPRINTER2.POMAIN
_local_15|<string>|VSPRINTER2.IMG2
_local_16|<string>|oipiarchive_TVCORYX
_local_17|<string>|ORYXADM_MAIN
_local_18|<unassigned>|
_local_19|<unassigned>|
_local_20|<unassigned>|
_local_21|<unassigned>|
_local_22|<unassigned>|
_local_23|<unassigned>|
_local_24|<unassigned>|
_local_25|<unassigned>|
_local_26|<unassigned>|
_local_27|<unassigned>|
_local_28|<unassigned>|
_local_29|<unassigned>|
_local_30|<unassigned>|
_local_31|<unassigned>|
_local_32|<unassigned>|
_local_33|<unassigned>|
_local_34|<unassigned>|
_local_35|<unassigned>|
_local_36|<unassigned>|
_local_37|<unassigned>|
_local_38|<unassigned>|
_local_39|<unassigned>|
_local_40|<unassigned>|
_local_41|<unassigned>|
_local_42|<unassigned>|
_local_43|<unassigned>|
_local_44|<unassigned>|
_local_45|<unassigned>|
_local_46|<unassigned>|
_local_47|<unassigned>|
_local_48|<unassigned>|
_local_49|<unassigned>|
_local_50|<unassigned>|
_local_51|<unassigned>|
_local_52|<unassigned>|
_local_53|<unassigned>|
At 23 SEP 2020 08:19PM Joshua Goddard wrote:
or the fact that it treats 598.580596923827 as a string?
At 23 SEP 2020 08:20PM Joshua Goddard wrote:
the error message says "zero used", so does that means it could be whatever is 0 in the dump? So local_3 or local_7?
At 24 SEP 2020 08:18PM Joshua Goddard wrote:
Hi, could you please give me the source code. When I use process monitor, the crash doesn't happen…Maybe I will just add a delay to the code, as that seems to stop it.
At 25 SEP 2020 07:04AM Andrew McAuley wrote:
We'd suggest liaising with your local Works support. At first glance something containing a Window variable (@Window or MDIFRAME) is a little weird as that seems the most likely explanation for 598.580596923827.VSPRINTER2.OLE_OIPI. This in return would lead to the system being unable to retrieve numeric parameters from a target control correctly which could conceivably result in a DBZ error.
World leaders in all things RevSoft
At 26 SEP 2020 05:32AM Joshua Goddard wrote:
OK thanks. Not sure what "works" is. I will ask my team members.
At 28 SEP 2020 09:18PM Joshua Goddard wrote:
I asked my team members what "works" is, and they said this form is "works". So I guess we're back at square one. Anyway, I Put a delay(3) in the code, and that seems to have fixed it. This is just a hack though, and it would be better to know why this is happening. If you could let me look at the source code, that would be greatly appreciated.
At 28 SEP 2020 10:10PM Donald Bakke wrote:
I asked my team members what "works" is, and they said this form is "works". So I guess we're back at square one.
WORKS is a support subscription. This is the WORKS forum, which you are granted access to because you are a WORKS subscriber (or member).
When Andrew suggest you contact your "local Works support", he was referring to the agency that resells your company the WORKS subscription. My guess is that this is Richard Bright. The reason for this is because your WORKS subscription reseller can work with you directly to resolve problems with your product. Yes, this forum is also intended to help, but there is only so much that can be done through this medium. Your situation seems like directed support is in order.
At 28 SEP 2020 11:35PM Joshua Goddard wrote:
I see. I will try to contact him…
thanks
At 29 SEP 2020 03:24AM Andrew McAuley wrote:
The way you describe the problem it is unlikely that access to the OIPI2_PRINTHEADER source would help (not that anyone here other than Rev could provide it) as the most likely answer is that it is taking a while to instantiate the OIPI control correctly in SET_PRINTER2 so it isn't quite there by the time you get to the header routine.
If you preload SET_PRINTER2 by using a dummy call you don't care about, does the issue persist?
Apologies for the lack of clarity and thanks to Don for clearing that up. Basically your annual Works subscription provides access to software updates and support from the manufacturer for documented features. It also provides access to this forum where there is a mixture of manufacturer and peer support.
World leaders in all things RevSoft
At 29 SEP 2020 05:01AM Joshua Goddard wrote:
Thanks, that makes sense because it explains why the delay(3) works. It also explains why if the program fails , it is unlikely to fail again on subsequent runs. I will try preloading it.
Thanks
At 04 NOV 2020 05:57PM Joshua Goddard wrote:
This error is still happening despite the delay I put in the code. I suspect I need to put more delays in the code, but not sure where.
Anyway, could you please explain how I can make a dummy call to set_printer2? Might also have to do it for get_printer2, as I think it sometimes crashes in there too.
At 04 NOV 2020 06:12PM Andrew McAuley wrote:
The idea would be that you make a set or get or both print a call in your application initialisation so that by the time you need to use it you are confident that the routines you need are in memory. Of course this only applies to external objects as openinsight will take things on or off the stack as it deems appropriate.
World leaders in all things RevSoft
At 04 NOV 2020 06:12PM Andrew McAuley wrote:
This error is still happening despite the delay I put in the code. I suspect I need to put more delays in the code, but not sure where.
Anyway, could you please explain how I can make a dummy call to set_printer2? Might also have to do it for get_printer2, as I think it sometimes crashes in there too.
World leaders in all things RevSoft
At 04 NOV 2020 09:46PM Joshua Goddard wrote:
Hi, I don't know what to call. Do you have any code examples? Would is just be set_prinert("sfdjsajsfajksfaj") and get_printer("sadsadksadk")?
At 05 NOV 2020 11:17AM bshumsky wrote:
Hi, I don't know what to call. Do you have any code examples? Would is just be set_prinert("sfdjsajsfajksfaj") and get_printer("sadsadksadk")?
Hi, Joshua. Yes, instead of calling just SET_PRINTER() and GET_PRINTER() (which then "redirects" behind the scenes to the proper routine), I think the suggestion is that you'd put in a call explicitly to SET_PRINTER2() and GET_PRINTER2(). They are exactly the same as SET_PRINTER() and GET_PRINTER(), they just bypass the "redirection" and go directly to the proper routine. Remember you will need to DECLARE SUBROUTINE/DECLARE FUNCTION as well.
(And just FYI, the same thing is true with SET_PRINTER1() and GET_PRINTER1() - these calls will go directly to the "classic" OIPI routines).
Hope that helps,
- Bryan Shumsky
At 05 NOV 2020 05:32PM Joshua Goddard wrote:
Thanks, I will give this a try.
At 05 NOV 2020 08:55PM Joshua Goddard wrote:
Thanks
2 more questions though:
1. What arguments should I pass to get_printer2 and set_printer2?
2. What exactly is the thing that gets created after making the above calls, and is there any way for me to check if it exists (not necessarily programmatically, just for debugging purposes to help me understand the issue).
At 06 NOV 2020 06:59AM D Harmacek wrote:
If you are going to use the driver-specific calls to set_printer1 or get_printer2 and set_printer2 or get_printer2 then make sure you have ALL of your routines use that specific version. I had some non-driver specific calls in a subroutine. I had to add a parameter to that subroutine flagging which driver type to use, 1 or 2.
Dave Harmacek - Harmacek Database Systems - near Boston, MA USA
At 06 NOV 2020 11:09PM Barry Stevens wrote:
Thanks
2 more questions though:
1. What arguments should I pass to get_printer2 and set_printer2?
2. What exactly is the thing that gets created after making the above calls, and is there any way for me to check if it exists (not necessarily programmatically, just for debugging purposes to help me understand the issue).
I am sure he means change all your set/get_printer(….) calls to set/get_printer2(….)