Setlinestyle

[gabams]

Hi,

I'm quite new to Fortran, I'm programming a standard graphics application, and would like to draw a black dashed line. I believe I've applied exactly what I found in the help of Visual Fortran, ie :

INTEGER(2) style

style = #FF00

CALL SETLINESTYLE(style)
oldcolor = SETCOLORRGB(#0000000)

CALL MOVETO_W(GITO,Y1OLD,DumIF)
status = LINETO_W(GITN,Y1NEW)

But I always get a solid line instead of adashed line.

If I doa GETLINESTYLE()after the CALL SETLINESTYLE(style), I see that indeed, I don't have the right numerical value for the style. In base 10, the style should have value 65280 (corresponds to FF00), but I get -256 instead of that.

Does anyone have an idea on how to fix this problem ?

Thanks a lot

Gab

[Jugoslav_Dujic]

Your code is (almost) fine. A detailed explanation is below -- however, I'll try to offer a direct solution first (I haven't worked with QuickWin for ages, though, so try for yourself):

Lines with pattern SetLineStyle draw the binary "1"s with color set by SETCOLOR(RGB), and binary "0"s with color set with SETBKCOLOR(RGB). This is not, however, clearly documented in the help -- see the "SETFILLMASK" entry, which (as far as I know) works the same way. Thus, if your SetBkColor is black and your SetColor is also black, you get a black on black line. Unfortunately (again, as far as I know), there's no way to tell QuickWin to keep binary "0"s as "transparent", i.e. retain the "old" colors of pixels beneath.

Regarding bit patterns: 1) Fortran has only signed types 2) with signed types, the most-significant bit (MSB) is used to denote the sign. Thus, "FF00" has the MSB of 1 in an integer(2), and the debugger reads it as -256. Since the range of signed integer(2) is -32768:-32767, 65280 can't fit. However, if you use only Hex notation, you're OK (since in case of SETLINESTYLE what matters is bit-pattern rather than decimal value). Potential problems can occur when you perform typecasts from e.g. integer(2) to integer(4), because you don't get a bit-by-bit copy -- instead, the MSB is treated as sign-bit and handled specially:

integer(2):: j = "FF00"

integer(4):: k

k = j

write(*,"(Z8.8, i10)") k,k !Prints "FFFFFF00 -256"

To achieve bit-by-bit copy in such situations, you have to use ZEXT or TRANSFER intrinsics:

k = zext(j, kind(k))
write(*,"(Z8.8, i10)") k,k !Prints "0000FF00 65280"

k = transfer(j, k)
write(*,"(Z8.8, i10)") k,k !Prints "0000FF00 65280"

(This partis not related with your problem, but I hope it helps to know)

Jugoslav

[david_jones]

Just to note that I have working code, under CVF but it should still apply to IVF, that uses the call

CALL SETLINESTYLE(#8888)

to set a dashed line and
CALL SETLINESTYLE(#FFFF)

to reset to full line.

[gabams]

Jugoslav: thanks a lot for the explanation about the hex value, I didn't know that! I have specified

oldcolor= SETBKCOLOR(#FFFFF)

in my subroutine where I draw the line, but this doesn't work either (actually, I had already specified it in another subroutine called before).

David: I actually use CVF myself, but the SETLINESTYLE(#8888)doesn't seem to work....

So both of you, thanks a lot for answering so quickly! I'll try some new stuff, and if the SETLINSTYLE() doesn't work, I'll just put a counter in my subroutine and ask to draw the line everyN timesteps, this should work!

Gab

[Jugoslav_Dujic]

Gab,

I did a quick test and it appears that I was wrong -- SetBkColor(Rgb) does not affect the output of subsequent SetLineStyle/LineTo, and "missing" pixels are indeed transparent (retained as-is):

Code:

PROGRAM Pinky

USE DFLIB

IMPLICIT NONE

INTEGER::   iStyle, i
TYPE(XYCOORD)::   XY

WRITE(*,*)

CALL SetColorRgb(#FFFFFF)
CALL SetBkColorRgb(#FFFF)
i = Rectangle($GFILLINTERIOR,0,0,100,50)

CALL SetColorRgb(#FFC0FF)
i = Rectangle($GFILLINTERIOR,0,50,100,100)

CALL SetColorRgb(#FF)
CALL SetLineStyle(#FF00)

CALL MoveTo(1,1,XY)
i = LineTo(100, 100)

DO WHILE(.TRUE.)
   CALL SLEEPQQ(100)
END DO

END PROGRAM Pinky

And it also works with an integer(2) variable instead of a literal #FF00 as an actual argument. So, something else appears tobe wrong -- a stupid question -- do you perhaps overwrite the line later?

Jugoslav

[gabams]

Jugoslav,

thanks to your small example, I finally understood what was going wrong in my program, and it's a very stupid thing:

I actually have to draw a function point by point between x=0 and 10 000, and my timestep is 0.1

So what happens is simply that I do get a dashed line using SetLineStyle, but the dashes are too small for me to see, since I each time draw a line of length 0.1, and myscreen is designed to show me a total length of 10 000.

I checked that this was indeed the case by doing a zoom on my function: I can see the dashes doing a zoom.

(I understood this problem thanks to your LineTo(100, 100), I there saw that the coordinates you used were far bigger than mine...)

Thanks for your help

Gab

[Jugoslav_Dujic]

POLYGON_W worksalmost fine:

Code:

DO i=1,1000
   XY(i)%wx = (i/10.)
   XY(i)%wy = 50 + sin((i-500.)/50.)*50.
END DO
i = Polygon_W($GBORDER, XY, 1000)

but it connects thefirst and last point. There is also POLYLINE, which does not do that, but does not have the _W version, so you'd have to convert the coordinates yourself beforehand using GETVIEWCOORD_W. Pick your choice.

Jugoslav