|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
sparge
Joined: 11 Apr 2005 Posts: 371
|
Posted: Tue Jan 18, 2011 1:24 pm Post subject: 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
-----
</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 |
|
|
jjgermis
Joined: 21 Jun 2006 Posts: 404 Location: N�rnberg, Germany
|
Posted: Tue Jan 18, 2011 3:22 pm Post subject: |
|
|
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 |
|
|
sparge
Joined: 11 Apr 2005 Posts: 371
|
Posted: Tue Jan 18, 2011 4:32 pm Post subject: |
|
|
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 |
|
|
sparge
Joined: 11 Apr 2005 Posts: 371
|
Posted: Thu Jan 20, 2011 1:12 pm Post subject: |
|
|
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 . 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 |
|
Back to top |
|
|
sparge
Joined: 11 Apr 2005 Posts: 371
|
Posted: Thu Jan 20, 2011 1:47 pm Post subject: |
|
|
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 |
|
|
sparge
Joined: 11 Apr 2005 Posts: 371
|
Posted: Tue Jan 25, 2011 1:45 pm Post subject: Anyone else care to try this please? |
|
|
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 |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2391 Location: Yateley, Hants, UK
|
Posted: Tue Jan 25, 2011 7:31 pm Post subject: |
|
|
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 |
|
|
Robert
Joined: 29 Nov 2006 Posts: 449 Location: Manchester
|
Posted: Fri Jan 28, 2011 5:46 pm Post subject: |
|
|
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 |
|
|
sparge
Joined: 11 Apr 2005 Posts: 371
|
Posted: Fri Jan 28, 2011 6:49 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Wed Feb 02, 2011 11:51 am Post subject: |
|
|
OK I'll take a look at the documentation. |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Wed Feb 02, 2011 1:14 pm Post subject: |
|
|
%ga did not work on radio buttons, but it does on check boxes. There is an earlier post describing this.
Ian |
|
Back to top |
|
|
sparge
Joined: 11 Apr 2005 Posts: 371
|
Posted: Wed Feb 02, 2011 1:20 pm Post subject: Re: |
|
|
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 |
|
|
Wilfried Linder
Joined: 14 Nov 2007 Posts: 314 Location: D�sseldorf, Germany
|
Posted: Thu Feb 03, 2011 9:55 am Post subject: |
|
|
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 |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2391 Location: Yateley, Hants, UK
|
Posted: Thu Feb 03, 2011 2:52 pm Post subject: |
|
|
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 |
|
|
sparge
Joined: 11 Apr 2005 Posts: 371
|
Posted: Thu Feb 03, 2011 3:58 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
|
|
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
|