Format code conundrum

<edit> My apologies folks, it seems I have posted a red herring below. I just tried to revert to my 'original' code and still got the same access violation, so the cause is in some other change I have made, elsewhere than the simpleplot calls. It appears to be associated with a callback function I have introduced. Curiously, I get most information from the release build, but I am as yet unclear as to the problem. I may follow up in due course 😮ops:

</edit>

One of the ways to render ClearWin+ code more digestible is to break it down into a series of continuation statements, each with own individual format code and arguments. This works well as long as individual format codes do not have long standard character strings [blahblah...] associated with them. In this case, a feature that works for some format codes is to append @ instead of [blahblah...] and supply the standard character string as an additional argument - this allows a long string to be assembled neatly and passed as a character variable.

My current issue is that, having dipped a toe in the water of Simpleplot, and got basic graphs working using the %pl format code, I now want to start exerting more control over the result, without (yet) going to the extent of full programmatic control. This means that the list of options is already starting to become quite unwieldy. Whilst it's easy enough to do the brute force continuation line thing, I thought I would see if I could do better.

I established that the @ trick does not work for %pl. Then I hit on a bright idea, of passing the entire format code string '%pl[blahblahblah...]', the first argument to winio@, as a character variable argument instead. So I tried, in an obvious pseudocode:

chapel = '%pl[blahblahblah...]    ...' !end result, assembled upstream
i = winio@ (trim (chapel), argument1, argument2, ...)

but this leads to an access violation. I have checked in sdbg that I have assembled the character variable correctly, so as far as I can see, the call above should be precisely equivalent to:

i = winio@ ('%pl[blahblahblah...]', argument1, argument2, ...)

If I don't use trim,and rely on the compiler to lop off the trailing spaces, I get the same result, so it can't be to do with using trim inside the winio@ call.

I haven't ever tried this bright idea on Clearwin+ format codes, and so I don't know if it would also fail there. But I am wondering if the issue is that %pl is a '3rd party' format code, as it were, and thus maybe not subject to the same rules of engagment? I can certainly see that would explain why the @ trick does not work.

Does anyone have any words of wisdom, please?

The following works for me: WINAPP INTEGER i,x,winio@,N PARAMETER(N=1000) REAL8 p1,p2,p3,y(N) character(len=128) :: option c---Prepare the data. p1=1.5 p2=150.0 p3=15 x=0 DO i=1,N y(i)=p1sin(x/p3)*exp(-x/p2) x=x+1 ENDDO c---Display a window containing the graph. i=winio@('%ww[no_border]%ca[SIMPLEPLOT-Damped wave]%pv&') option = '%pl[x_axis=Time(Miliseconds),y_axis=Amplitude,]' i=winio@(option,400,300,N,0.0D0,1.0D0,y) END

Yup, something similar was working for me too, and now it's not, and I can't for the life of me figure out what subtle change I've made to break it. Gotta go now, more tomorrow or Thursday.

Hmmm ... OK, I have now isolated the problem, and it is quite interesting. Appears to be nothing to do with Simpleplot, but I have not attempted to eliminate the lines of code that use it, for reasons that will become clear below. The following code illustrates the issue:

        program pltest
        integer, parameter :: numpla = 3, size = 10
        integer iodial, s, hanpla (numpla), hanplacur
        double precision g (size), h (size), i (size)
!        hanplacur = 1
        do s = 1, size
          g (s) = s
          h (s) = s* s - dble (1)
          i (s) = dble (1)/ (s*s + dble (1))
        end do
        iodial = winio@ ('%sh&', hanpla (3))
        iodial = winio@ ('%ca[Blah1]&')
        iodial = winio@ ('%pl[style=1,x_array,x_axis=H,y_axis=I]', 400, 400, size, h, i)
        iodial = winio@ ('%sh&', hanpla (2))
        iodial = winio@ ('%ca[Blah2]&')
        iodial = winio@ ('%pl[style=1,x_array,x_axis=H,y_axis=G]', 400, 400, size, h, g)
        iodial = winio@ ('%sh&', hanpla (1))
        iodial = winio@ ('%ca[Blah3]&')
        iodial = winio@ ('%pl[style=1,x_array,x_axis=I,y_axis=G]', 400, 400, size, i, g)
        iodial = winio@ ('%ca[Blablah]&')
        iodial = winio@ ('%`*ps&', numpla, hanpla (3), hanpla (2), hanpla (1), hanplacur)
        iodial = winio@ ('%ff%nl%cn%`bt[OK]')
        stop  
        end program pltest        

With the immediately previous version of this code, with less anodyne captionage (but everything else exactly the same), the /CHECKMATE and /DEBUG builds gave an access violation, whereas the /RELEASE build gave a runtime error on first run, and on subsequent runs, ran without reporting an error.

It is also the case that in cutting the code down to that stage, the /DEBUG and /RELEASE builds did not misbehave reliably - the error appeared to manifest and then disappear with the same code, making life somewhat difficult 😄 . See below.

Finally, I observe that when I tried and failed to reproduce the run time error that the /RELEASE build had already given me, I went back to look at /CHECKMATE and /DEBUG behaviour, and in both cases, Plato told me that the executable was out of date and offered to rebuild it, even though I had already built and run both those alternative versions. So it seems to me that whatever is going wrong has knock-on implications for subsequent builds. It's all rather odd.

In fact, I have now established that this insistence that the executable is out of date is quite reproducible, if Plato is alternated between /RELEASE and /DEBUG modes, without changing the source code. On my machine, at any rate: 1 - I built all three versions of the executable 2 - I ran the /DEBUG version and it access violated 3 - I switched Plato to /RELEASE mode and tried and run. Plato said that the executable was out of date (even though it wasn't). I rebuilt and ran it, without an error. 4 - I switched Plato back to /DEBUG mode and tried to run. Plato said that the executable was out of date (even though it wasn't). I rebuilt and ran it, and it access violated. 5 - Go to 3 😄

If the comment line is uncommented, all builds run as they should. In my original code, failure to initialize the variable in question was an oversight - however, whilst it is clearly good practice to initialize variables 😃 , as I read the manual, it should not be necessary here because the variable is allegedly defaulted to a value of 1. Even if not, the /CHECKMATE build at least should diagnose an attempt to use an uninitialized variable, not access violate, and the other two builds should (arguably) give a more informative runtime error.

Just before posting, I went back and changed the captions of the property sheets and the main window to something anodyne (as per the code finally posted above), and rebuilt. The /RELEASE and the /DEBUG builds both ran OK, and this time it was the /CHECKMATE build that disgorged the following runtime error diagnostics. Now the /DEBUG build has started to access violate again.

Andy

Runtime error from program:c:\apps\spargeware\ftn95 & ilib\deadbeef\pltest.exe Access Violation The instruction at address 100870bb attempted to read from location 0000000c

10086e42 property_sheet_procedure@16#70 [+0279] 7e418734 routine at address 7E418734 [+0000] 7e418816 routine at address 7E418816 [+0000] 7e4189cd routine at address 7E4189CD [+0000] 7e4196c7 routine at address 7E4196C7 [+0000] 03ba4b90 HandleAnyOutstandingMessages(void)#B [+003e] 03ba60ba JBWN00_INTR_CREATE_WINDOW [+0037] 03b97530 JBWN04 [+017e]

eax=00000003 ebx=0000040b ecx=00000000 edx=00000000 esi=10086e42 edi=00000000 ebp=0360d414 esp=0360d308 IOPL=0 ds=0023 es=0023 fs=003b gs=0000 cs=001b ss=0023 flgs=00010246 [NC EP ZR SN DN NV]

100870bb mov eax,[ecx+0xc] 100870be push [eax+0x108] 100870c4 call 1014b6c0

Seems I exceeded a post length because some important stuff (now below my name below) got truncated. No bad thing because I have more to report now - namely that the three property sheet handles, which are supposed to be outputs from %sh, are all being set to a value of -1 ... so that explains why I am getting into fresh trouble, back in my original code, when I try switch visible sheet under program control, based on the handle of the current sheet.

This business of whether the property sheet handle is an input or an output is all starting to sound horribly familiar. But I can't fnd anything on the forum to support that feeling?

Andy

Just before posting, I went back and changed the captions of the property sheets and the main window to something anodyne (as per the code finally posted above), and rebuilt. The /RELEASE and the /DEBUG builds both ran OK, and this time it was the /CHECKMATE build that disgorged the following runtime error diagnostics. Now the /DEBUG build has started to access violate again.

Andy

Runtime error from program:c:\apps\spargeware\ftn95 & ilib\deadbeef\pltest.exe Access Violation The instruction at address 100870bb attempted to read from location 0000000c

10086e42 property_sheet_procedure@16#70 [+0279] 7e418734 routine at address 7E418734 [+0000] 7e418816 routine at address 7E418816 [+0000] 7e4189cd routine at address 7E4189CD [+0000] 7e4196c7 routine at address 7E4196C7 [+0000] 03ba4b90 HandleAnyOutstandingMessages(void)#B [+003e] 03ba60ba JBWN00_INTR_CREATE_WINDOW [+0037] 03b97530 JBWN04 [+017e]

eax=00000003 ebx=0000040b ecx=00000000 edx=00000000 esi=10086e42 edi=00000000 ebp=0360d414 esp=0360d308 IOPL=0 ds=0023 es=0023 fs=003b gs=0000 cs=001b ss=0023 flgs=00010246 [NC EP ZR SN DN NV]

100870bb mov eax,[ecx+0xc] 100870be push [eax+0x108] 100870c4 call 1014b6c0

I have been doing a little more work on this. The code below illustrates a FTN95 bug as far as I can see. The text below is the bug report I have just submitted to Silverfrost. Would anyone else care to investigate on their own machine?

Andy

The code below is simpler and rules out the (unlikely) possibility that an interaction with SIMPLEPLOT was responsible.

The design intent of the code is that when the user selects a property sheet, the radio button display is updated - and conversely, the radio button display can be used to change the property sheet being displayed. What actually happens is this: if the currently selected sheet is changed, the radio buttons do not get updated accordingly, because the do loop in callback function chash does not match shcur to any element of sh (:). conversely, if the currently selected radio button is changed, the code either generates a runtime error (/RELEASE) or an access violation (/DEBUG or /CHECKMATE), because the callback function charb tries to display the sheet with handle -1 which of course does not exist.

As before, it is necessary to initialize shcur to avoid an immediate runtime error (/RELEASE) or access violation (/DEBUG or /CHECKMATE). If ClearWin+ was doing what it is supposed to according to the documentation, every element of sh(:) would have a different value and shcur would always be equal to one of those values.The problem is that sh (:) and shcur are not being set correctly by ClearWin+. Every element of sh (:) is being set to -1. I have no idea what shcur is being set to, because I can't break into the code and inspect it if I don't initialize it.

Andy

    program sheety
    use callbacks
    integer iodial
    shcur = 1
    rb (:) = 0
    rb (1) = 1
    iodial = winio@ ('%sh&', sh (3))
    iodial = winio@ ('%ca[Blah1]')
    iodial = winio@ ('%sh&', sh (2))
    iodial = winio@ ('%ca[Blah2]')
    iodial = winio@ ('%sh&', sh (1))
    iodial = winio@ ('%ca[Blah3]')
    iodial = winio@ ('%ca[Blahblah]&')
    iodial = winio@ ('%^`*ps&', numpla, sh (3), sh (2), sh (1), shcur, chash)
    iodial = winio@ ('%ff%nl&')
    iodial = winio@ ('Specify a sheet&')
    iodial = winio@ ('%ff%nl&')
    iodial = winio@ ('%`*ga&', numpla, rb (3), rb (2), rb (1))
    iodial = winio@ ('%^rb[Blah1]%nl&', rb (3), charb)
    iodial = winio@ ('%^rb[Blah2]%nl&', rb (2), charb)
    iodial = winio@ ('%^rb[Blah3]%nl&', rb (1), charb)
    iodial = winio@ ('%ff%nl%cn%`bt[OK]')
    stop
    end program sheety

    module callbacks
    use clrwin
    integer, parameter :: numpla = 3
    integer pla, rb (numpla), sh (numpla), shcur
    contains
    integer function chash ()
    chash = 2
    do pla = 1, numpla
      if (sh (pla) .eq. shcur) then
        rb (pla) = 1 ! NB gang format should take cure of setting other two to 0
        call window_update@ (rb (pla))
      end if
    end do
    return
    end function chash
    integer function charb ()
    charb = 2
    do pla = 1, numpla
      if (rb (pla) .eq. 1) then
        shcur = sh (pla)
        call see_propertysheet_page@ (shcur)
      end if
    end do
    return
    end function charb
    end module callbacks

Andy

I note that you used a %ga, and this is known to have difficulties. I've got one or two codes where it works, and one or two where it definitely doesn't, and so I deal with all the codes in a callback, and would do so automatically now.

Eddie

From the documentation of %ps (at http://www.silverfrost.com/ftn95-help/clearwinp/formats/_ps.aspx):

The program can change the sheet number by changing sheet_n and calling see_propertysheet_page@(sheet_n).

So the code to make the property sheet follow the radio button would be:

if (rb (pla) .eq. 1) then
  shcur = pla
  call see_propertysheet_page@ (shcur)
end if

OK, but the documentation for %sh says that sheet1, sheet2, ... , sheetN are handles that are returned by %sh and are inputs to %ps. The clear implication is that sheetn must be set to one of sheet1, sheet2, ... sheetN, not to one of 1, 2, ... , N. In fact, sheet1, sheet2, ... , sheetN seem to be merely syntactical placeholders.

So at the very least, the documentation for %sh should be amended to make it clear that they are 'internal state' variables, and the documentation for %ps should be amended to make it clear that sheetn refers to the index (1, 2, ... , N) of the current sheet and *not *its handle (sheet1, sheet2, ... , sheetN). This being so, it would also be logical to change the nomenclature, retaining sheetn but using handle1, handle2, ... , handleN instead, for example.

Oh, and by the way Eddie, your observation about %ga is also pertinent, because I have stepped through the code I posted and it is indeed not working as per design intent. I seem to recall you posted about this quite some time ago, so it was a timely reminder - thank you.

OK I'll take a look at the documentation.

%ga did not work on radio buttons, but it does on check boxes. There is an earlier post describing this. Ian

Quoted from IanLambley %ga did not work on radio buttons, but it does on check boxes. There is an earlier post describing this. Ian

If so, that's a bit contrary, because there is somewhere in the documentation a note that whilst radio buttons and checkboxes (the only difference being the presence or absence of a grave accent on the %rb format code) can both be ganged, ganging checkboxes is contrary to checkbox design intent - they are intended to be independent of one another.

Radio buttons (circle-shaped, %rb) can be ganged, check boxes (square-shaped, %`rb) not. At least in my version of Clearwin (??) . Regards - Wilfried

Whether or not it says in the Windows User Experience Guidelines that radio buttons can be ganged, and check boxes shouldn't be ganged, that is the long term convention.

In my experience of Clearwin, much of the time %ga works as advertised, and allows you to automatically gang radio buttons. I suspect that it works with check boxes too. However, sometimes, and for reasons completely undecypherable by me, the automatic ganging doesn't work. If you encounter a case like that, the answer is to take out the %ga format code, and gang the radio buttons yourself by having a callback function for each of them, and setting the codes manually.

If you have 2 radio buttons, you can set or unset one, and the other responds automatically. If you have 3 or more in a group, your callback can only respond to 'set', as you don't know which other to set in place of one that you have 'unset'.

Only last week I wrote 3 ganged groups into my code, and they all worked. Things like that make me think the problem is with me. But then all of a sudden, something won't work. For a while, I avoided %ga. But it is very useful, and easier than coding it yourself. The advice to be prepared to do it yourself if you hit a problem case stops you tearing your hair out ....

Eddie

Hehe ... Eddie, I genuinely was not sure whether the Windows User Experience Guidelines actually existed, or were just plausible-sounding fiction dreamt up by your fertile imagination. So I Googled, and lo! they do exist, all 46 Mb of them, which I am downloading for spiritual eddiefication. I was hoping, by now, to have typed 'have downloaded', but they are arriving at such an infernally slow speed (2 hours 48 minutes left as I type) that I'm just going to post instead. I will pass on what they have to say on the subject of ganging in due cours. Probably tomorrow at this rate 😉

Hi Sparge,

You will find out that MS keep changing the goalposts, and that the Office 2007/2010 'ribbon' is now de rigeur. They do make some very interesting suggestions however.

Mostly, engineers and scientists usually don't follow the paradigm very exactly, and so this irritates users. My favourite example is the standard callback 'CONFIRM_EXIT', which is exactly opposite to the way most applications work. With CONFIRM_EXIT, Yes means Quit immediately and throw away my stuff, but most applications Yes means Now save my stuff, and give me a chance not to exit!

Enjoy your read.

Eddie