forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Format code conundrum
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Tue Jan 18, 2011 1:24 pm    Post subject: Format code conundrum Reply with quote

<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 Embarassed

-----
</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:

Code:

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:

Code:

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?


Last edited by sparge on Thu Jan 20, 2011 4:17 pm; edited 1 time in total
Back to top
View user's profile Send private message Send e-mail
jjgermis



Joined: 21 Jun 2006
Posts: 404
Location: Nürnberg, Germany

PostPosted: Tue Jan 18, 2011 3:22 pm    Post subject: Reply with quote

The following works for me:
Code:
      WINAPP
      INTEGER i,x,winio@,N
      PARAMETER(N=1000)
      REAL*8 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)=p1*sin(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
Back to top
View user's profile Send private message
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Tue Jan 18, 2011 4:32 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Send e-mail
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Thu Jan 20, 2011 1:12 pm    Post subject: Reply with quote

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:
Code:

        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 Very Happy . 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 Very Happy

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 Smile , 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
Back to top
View user's profile Send private message Send e-mail
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Thu Jan 20, 2011 1:47 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Send e-mail
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Tue Jan 25, 2011 1:45 pm    Post subject: Anyone else care to try this please? Reply with quote

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 (Smile.
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(Smile would have a different value and shcur would always be equal to one of those values.The problem is that sh (Smile and shcur are not being set correctly by ClearWin+. Every element of sh (Smile 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 (Smile = 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
Back to top
View user's profile Send private message Send e-mail
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1683
Location: Yateley, Hants, UK

PostPosted: Tue Jan 25, 2011 7:31 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 223
Location: Manchester

PostPosted: Fri Jan 28, 2011 5:46 pm    Post subject: Reply with quote

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:

Code:

if (rb (pla) .eq. 1) then
  shcur = pla
  call see_propertysheet_page@ (shcur)
end if
Back to top
View user's profile Send private message Visit poster's website
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Fri Jan 28, 2011 6:49 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Send e-mail
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5043
Location: Salford, UK

PostPosted: Wed Feb 02, 2011 11:51 am    Post subject: Reply with quote

OK I'll take a look at the documentation.
Back to top
View user's profile Send private message
IanLambley



Joined: 17 Dec 2006
Posts: 468
Location: Sunderland

PostPosted: Wed Feb 02, 2011 1:14 pm    Post subject: Reply with quote

%ga did not work on radio buttons, but it does on check boxes. There is an earlier post describing this.
Ian
Back to top
View user's profile Send private message Send e-mail
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Wed Feb 02, 2011 1:20 pm    Post subject: Re: Reply with quote

IanLambley wrote:
%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.
Back to top
View user's profile Send private message Send e-mail
Wilfried Linder



Joined: 14 Nov 2007
Posts: 303
Location: Düsseldorf, Germany

PostPosted: Thu Feb 03, 2011 9:55 am    Post subject: Reply with quote

Radio buttons (circle-shaped, %rb) can be ganged, check boxes (square-shaped, %`rb) not. At least in my version of Clearwin (??)
.
Regards - Wilfried
Back to top
View user's profile Send private message Visit poster's website
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1683
Location: Yateley, Hants, UK

PostPosted: Thu Feb 03, 2011 2:52 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Thu Feb 03, 2011 3:58 pm    Post subject: Reply with quote

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 Wink
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group