DRAW_CHARACTERSd@ crashing

this function fails especially when application compiler in with /undef

hopefully the traceback can help isolate the issue

i have included my function S_IGRCHAROUT() to illustrate how i call DRAW_CHARACTERSd@

regards

steve

Runtime error from program:c:\apps_cpi\bin\star.exe Access Violation The instruction at address 070c380e attempted to read from location 0b2d7298

070c37e8 TextOutAW(<ptr>void,int,int,<ptr>constÄchar,int) [+0026]

0712258e __win_draw_text_ll(<ptr>char,int,int,int,constÄint)#75 [+0203]

07122982 __win_draw_text_d [+0109]

00c8b980 S_IGRCHAROUT [+0154]

DRAW_TEXT_AT - in file dndstr2.for at line 3382 [+0133]

DRAW_BOILER_INFO - in file dndstr2.for at line 3648 [+03a9]

DRAW_ENTITY_INFO - in file dndstr2.for at line 3245 [+019e]

DRAW_ENTITY_APP2 - in file dndstr1.for at line 5777 [+10bc]

eax=0b2d7008 ebx=000880e8 ecx=000880e8 edx=0706dfa4 esi=0706e12c edi=000880e8 ebp=0706de54 esp=0706de28 IOPL=1 ds=0023 es=0023 fs=003b gs=0000 cs=001b ss=0023 flgs=00010202 [NC OP NZ SN DN NV]

070c380e testb [eax+0x290],0x80 070c3815 je 70c38df 070c381b cmp [ebp+0x18],0x0

 SUBROUTINE S_IGRCHAROUT(XPOS, YPOS, STRING)

c =====================

  IMPLICIT NONE

  INCLUDE 'windowsx.inc'

  CHARACTER*( * ) STRING
  INCLUDE 'SALFINT.INC'

  DOUBLE PRECISION YPOS, XPOS,YPOS1, XPOS1
  INTEGER ILENG, LENGU, IXC, IYC

c INTEGER2 IXC2, IYC2, INTS, ICOL2 INTEGER4 IXC1, IYC1

  CHARACTER*81 CBUFF

  IF (THEIGHT .LE. 0 .OR. TWIDTH .LE. 0) RETURN

  CBUFF = ' '
  ILENG = LENGU(STRING)
  CBUFF = STRING(1:ILENG)
  CALL WCTONDC(XPOS, YPOS, IXC, IYC)

  IXC1 = INT(IXC - TWIDTH * 0.5D0)
  IYC1 = INT(IYC + THEIGHT * 0.5D0)

c CALL INT4_TO_INT2(IXC1, IXC2) c CALL INT4_TO_INT2(IYC1, IYC2) xpos1 = ixc1 ypos1 = iyc1

c ICOL2 = INTS(ICOL) c CALL DRAW_CHARACTERS@(CBUFF(1:ILENG), IXC1, IYC1, ICOL_CURRENT) CALL DRAW_CHARACTERSd@(CBUFF(1:ILENG), xpos1, ypos1, ICOL_CURRENT) c CALL DRAW_characters@(CBUFF(1:ILENG), IXC2, IYC2, ICOL_CURRENT) c CALL DRAW_TEXT@(CBUFF(1:ILENG), IXC2, IYC2, ICOL_CURRENT) C CALL DRAW_TEXT@(CBUFF(1:ILENG), IXC2, IYC2, INTS(ICOL_CURRENT))

c CALL DRAW_TEXT@(CBUFF(1:ILENG)//CHAR(0),IXC2,IYC2,INTS(ICOL_CURRENT)) c CALL DRAW_TEXT@(STRING(1:ileng)//char(0),IXC2,IYC2,INTS(ICOL_CURRENT))

  END

Have you checked that CBUFF contains something sensible when the routine is called? Is the string long enough etc.

Quoted from PaulLaidler Have you checked that CBUFF contains something sensible when the routine is called? Is the string long enough etc.

paul as far as i can tell the text and the x-y locations are good. it happens in a variety of application as the first text written after a 'redraw' event. i was hoping that the address in the dll would give an indication of the problem

I would need a short sample program (that fails in this way) in order to identify the problem.

Paul

this problem is starting to become a serious issue with my clients

i cannot reproduce the effect with a simple example so i'm guessing that there is memory overwriting going on somewhere especially as it behaves differently with and without being complied with debug options

I did think that it maybe related to change in font type and/or size which are call just prior to the draw_charactersd@(...) call but eliminating such calls did not help

If i comment out the call to draw_charactersd@(...), the graphic surface refreshes as expected so i assuming all the underlying pointers etc. are sound.

the trace-back indicates that the issue is due to

Access Violation The instruction at address 070c380e attempted to read from location 0b2d7298

070c37e8 TextOutAW(<ptr>void,int,int,<ptr>constÄchar,int) [+0026]

i am assuming that argument 2->5 are the ones supplied via draw_charactersd@(...)

I am also assuming that the '<ptr>void' is somehow pointing to the the %gr object

is there anyway you can compile the salflibc.dll with the '/list' option to narrow down the line of code which actually fails?

any insights to this issue appreciated

regards

steve

Here is the listing which does not help me...

   5012   BOOL TextOutAW(HDC hdc, int nXStart, int nYStart, LPCSTR lpString, int cchString)          AT 0
   5013   {                                                                      AT 0
   5014     BOOL r=0;                                                            AT C
   5015     if(cw && cw->utf8)                                                   AT 13
   5016     {                                                                    AT 33

cw is the current ClearWin+ window which presumably still exists or does this happen after the window is assumed to be closed?

I would try something simple like

PRINT*, ILENG,xpos1,ypos1,ICOL_CURRENT
PRINT*, CBUFF(1:ILENG)
CALL DRAW_CHARACTERSd@(CBUFF(1:ILENG), xpos1, ypos1, ICOL_CURRENT) 

Paul

that for your efforts. as simple progrem does not xhibit the behaviour

i went back though my work logs to try an correlate when this behaviour started an it was about the time i added extended menus (%em). thus involve add a significant number of icons to the resource file (~160)

  IWIN = WINIO@('%mn[[|,mn_import/Import '...]]&',
 +        BUTTON_78)

  IWIN = WINIO@('%mn[[mn_export/export '...]]&', 
 +        BUTTON_79)

if i comment out all the 'mn_' in the *.rc file. the draw_charactersd@() function no longer crashes although i need to check it on an XP machine for a true comparison

i have tried compiling all the code with /full_debug (including service libraries) without any reported runtime issues

This has all the hallmarks of a memory corruption issue. are there any limitation to the number of icons or do need to increase the default stack heap settings?. the application themselves do not have large memory requirements for data.

does this shed any light

thanks

steve

I do not know of any limitations. But it would be a good idea to experiment with larger stack and/or heap sizes.

Windowsx.inc will be a user include file. From memory I think that the 'd' means that the arguments are double precision values.

The 'd' alternative routines have position co-ordinates etc with double precision values rather than integer values. They were introduced with gdi+ curve smoothing because there was some evidence that real values can give smoother curves. Also Clearwin+ is standardised on double rather than single precision values.

The original documentation appeared in clrwin.enh and may not have migrated from there.

In order to avoid the expected comment, I do know about the limitations of our current documentation.

This topic wasn't making the slightest sense to me until I followed my own advice and looked in the .ENH file!

I don't seem to have the windowsx.inc file, just windowsx.h (and in 2 places).

Re: 'may not have migrated from there' ... this phrase will go into my repertoire of favourite excuses:

Tax Inspector: 'You haven't paid your income tax'

LitusSaxonicum: 'Well, the money was in my bank account but it may not have migrated from there'

It has all the late 19th century style of Holmes laconically replying to one of Watson's stupid questions!

In mitigation, I am still 'out of office' so I am trying to help but I am limited to working from memory (that's my memory not the computer's). A search in ftn95.chm might reveal something.

Many questions in this forum can be answered via a keyword search of ftn95.chm. Then, as you are right to remind us, the enhancements file comes a close second.

Quoted from PaulLaidler Windowsx.inc will be a user include file. From memory I think that the 'd' means that the arguments are double precision values.

windowsx.inc is my idiosyncratic way of differentiating between just having a simple definition of winio@ (windows.inc) and including the entire <windows.ins> and some miscellaneous C_external definitions

it help my ancient code analysers from running out of memory

Sorry for the lack of response - out of office Going back the the original issue of the Draw_charactersd@() crashing for no apparent reason

i reverted back to the salflibc.dll/lib dated 27/4/2014 for both the complier and the runtime library from the latest prototype and what was a reproducible crash vanished. I'm guessing that there is something in the latest salflibc.dll or i didn't use the correct salflibc.lib that is causing the issue

I will try some experimentation to narrow down the cause

thanks for all you help

steve

Steve

Can you send me a short program that uses this call. I understand that a short program does not fail but it may help us to find the source of the problem.

A similar failure has been reported elsewhere on this forum so it looks like it is something that needs fixing.