| View previous topic :: View next topic |
| Author |
Message |
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7925
Location: Salford, UK
|
 Posted: Sat Nov 04, 2017 12:11 pm Post subject: |
 |
|
John: I don't have a date for the release of the personal edition 8.2.
Dan: The linker can't find the RGB@ in the module MODSURFPLOTDEMO. It is within that module or CB_SURFPLOT_PLOTTING that you need to say where RGB@ is to be found. As to the 5 bugs, I guess that you want me to locate the code and identify the "bugs" in the output for myself. |
|
| Back to top |
|
 |
John-Silver
Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley
|
| Posted: Sat Nov 04, 2017 12:21 pm Post subject: |
|
|
Re- your plot above Dan, I see 5 also, no wait 6 ! :-
1&2 strange that xaxis-title is again right justified, I thought the default had been corrected to centred ?
For Yaxis-title previously it was uncentred but towards top now it seems to be uncentred towards bottom. Odd that.
3. the curve still out of bounds
4. the yaxis title still interferes with the labels.
5. *New (?)* - tick marks along top border appear to be longer than those on rh border ? .... oh wait ... or is it because the spacing of the last 2 grid lines in x is incorrect ? (they look the same width to me) .... or both ?
On the horizontal gridlines (y dirn) the next to last 2 look to be equal.
Of course when I talk about gridlines it's really probably of origin a bug linked to the tick mark locations.
ah ! and the other of course ....
6. the Y scale is still 'unuseful' the way the spacing is chosen !!!!!!!!!!!!!
it's also different style (exponential) compared to x-axis (scientific powers) , this is probably due to the style being chosen independently as a function of each axis (or value even ?) there should really be a check incorporated to make sure the style of scale labels is the same and consistent aross the plot.
Last edited by John-Silver on Sat Nov 04, 2017 1:24 pm; edited 2 times in total |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2554
Location: Sydney
|
| Posted: Sat Nov 04, 2017 12:44 pm Post subject: |
|
|
Paul,
I am not sure what RGB@ is implemented as. I thought it would be an in-line or intrinsic function, but if I use the following, I get errors.
INTEGER,PARAMETER :: red = rgb@(255,0,0)
INTEGER,PARAMETER :: green = rgb@(0,255,0)
INTEGER,PARAMETER :: blue = rgb@(0,0,255)
Could this be allowed ?
Also, why "The linker can't find the RGB@"
John |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2816
Location: South Pole, Antarctica
|
| Posted: Sat Nov 04, 2017 12:50 pm Post subject: Re: |
|
|
| John-Silver wrote: | | Dan, just realised in the plot at the top of p. 12 the last label on X-axis (60) wėshould be 600 ! I think reading what you wrote that was done with simpleplot %pl right ? |
John,
Yes, this was bug with older Simpleplot %pl. The hack fix for that is simple: just take last X numbers not 599 or 600 but 601 or 610 with x_max=610 if it exists (I forgot if x_max exists for X axis, for the Y axis the y_max definitely exist) or with just adding fake number to the data at the end of X-Y array
With my single line example I found one minor problem more. But it pushed me to lose some time in photoshop for a dozen of plots
Paul,
Sorry, I did not understand both your answer and question. In the code on page 12 the offending line "include <clearwin.ins>" is marked as causing problems. And JohnCampbell confirmed this
As to question about 5 bugs the code is there and John-Silver named almost all of defects (I thought may be I am blinded with devilry  so I asked others to confirm if they also see the bugs and defects)
Last edited by DanRRight on Sat Nov 04, 2017 1:06 pm; edited 2 times in total |
|
| Back to top |
|
|
John-Silver
Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley
|
| Posted: Sat Nov 04, 2017 12:53 pm Post subject: |
|
|
just edited my reply with the 6th Dan :O)
unable to verify I generate same at the mo Dan but will try once perso version is released. As we know these things can be machine/OS related which is why it's good you asked the question. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7925
Location: Salford, UK
|
| Posted: Sat Nov 04, 2017 2:29 pm Post subject: |
|
|
John Campbell
RGB@ is implemented in salflibc.dll and clearwin64.dll so you won't be able to use it in an initialisation statement.
I normally just declare it as
INTEGER,EXTERNAL::RGB@ |
|
| Back to top |
|
|
John-Silver
Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley
|
| Posted: Sat Nov 04, 2017 8:48 pm Post subject: |
|
|
| wasn't this 'reverse RGB@ colours' problem highlighted on a completely different post recently and it was 'as designed/intended' ? (sorry can't remember which post) |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2816
Location: South Pole, Antarctica
|
| Posted: Sat Nov 04, 2017 10:50 pm Post subject: |
|
|
John,
No, Silicondale had similar problem, and he mentioned the reference on Web Standard which also always was RGB not BGR. |
|
| Back to top |
|
|
John-Silver
Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley
|
| Posted: Sat Nov 04, 2017 11:43 pm Post subject: |
|
|
| Dan, no I didn't mean as designed/intended by the standard but within FTN95. if I'm not mistaken. That's it it was Silicondale's problem I was thinking of. Wasn't the solution to just specify them in reverse order ? |
|
| Back to top |
|
|
silicondale
Joined: 15 Mar 2007
Posts: 245
Location: Matlock, Derbyshire, UK
|
| Posted: Sun Nov 05, 2017 10:54 am Post subject: |
|
|
I'm now not using rgb@ for this but coding the colours directly into the standard hex format #rrggbb thus:
| Code: | write(plxy,"(a,3z2.2,a)")
1 '%pl[colour=#', ir(i),ig(i),ib(i), ',x_array]' |
as I think it was Paul who suggested - and it works just fine. Contour plot of a hill as an example -
- Steve |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7925
Location: Salford, UK
|
| Posted: Mon Nov 06, 2017 4:44 pm Post subject: |
|
|
This is to correct an earlier post in this thread relating to the [colour=#rrggbb] option that can be used in %gr, %pl and other format codes.
You can set the %pl line colour via
call winopt@("%pl[colour=#rrggbb]")
where rr is the hex value for the red component etc.
For example:
call winopt@("%pl[colour=#FF0000]")
for red etc.
| Code: | write(str,"(a,z6.6,a)") "%pl[colour=#", RGB@(255,0,0), "]"
print*, str
|
produces the output
%pl[colour=#0000FF]
which is the wrong order so it is better to use z2.2 for each component in turn. |
|
| Back to top |
|
|
John-Silver
Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley
|
| Posted: Mon Nov 06, 2017 5:59 pm Post subject: |
|
|
Is this a native %pl only related bug then Paul ?
I assume it'll be fixed next beta release ? (as it's so much easier to use/track) |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7925
Location: Salford, UK
|
| Posted: Mon Nov 06, 2017 6:10 pm Post subject: |
|
|
| No it is not a bug. It is a correction to a previous post in this thread where I gave incorrect information. Both #rrggbb and RGB@ work correctly. My post was incorrect. |
|
| Back to top |
|
|
John-Silver
Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley
|
| Posted: Mon Nov 06, 2017 6:22 pm Post subject: |
|
|
P.S. - that plot of silicondale above has the axes titles right justified again.
Which version did you use for that Silicondale ?
(!!!! I've just realised how you've derived your username too !!!!! watch out California here comes the Peak District !) |
|
| Back to top |
|
|
silicondale
Joined: 15 Mar 2007
Posts: 245
Location: Matlock, Derbyshire, UK
|
| Posted: Mon Nov 06, 2017 11:01 pm Post subject: |
|
|
Hi John. You take today's star prize. The only person in 20 years who understood 'silicondale'. 
- Steve |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
