Odd behaviour of clearwin %rf ... and info on getting printer dpi

FIRST PROBLEM: I have a window with several %rd and %rf data entry boxes. The %rf boxes may be [initially_blank] in some cases, but not in others. There are also some sets of radio buttons 'ganged' together, which come later down the code, and beneath the %rf boxes in the window. At run time, if the user (me!) enters data in the %rf boxes, and then selects a different radio button, the last %rf box loses its contents. This does not happen if the radio buttons are selected before filling in the box, and it does not happen if the last %rf box is not [initially_blank], and it also does not happen if I physically move the ganged radio buttons up the code, so that they come earlier in the window .. although the testing of what does and doesn't work is far from exhaustive.

Does anyone have a similar experience, and what is the workaround please?

This example illustrates it:

   IA=WINIO@('%ca[Set limits]&')
   IA=WINIO@('Easting of lower left corner%ta%rf&'
 +           ,XXLOW)
   IA=WINIO@('%nl%nlNorthing of lower left corner%ta'//
 +           '%rf&',
 +            YYLOW)
   IA=WINIO@('%nl%nl%cn%2`ga&',
 +                          MODE(1),   MODE(2))
   IA=WINIO@('%ob[no_border]%rb[Landscape]&',        MODE(1))
   IA=WINIO@('%nl%nl%rb[Portrait]%cb&',   MODE(2))

   IA=WINIO@('%nl%nl%cn%6`bt[&OK]   %6bt[&Cancel]')

If the two %rf boxes are set [initially blank] then changing the %rb from 'Landscape' to 'Portrait' blanks out whatever was entered as YYLOW. (everything is declared with the correct type, and initial values have been given).

SECOND PROBLEM: Is there a way of finding out printer dpi so that I can produce a perfectly scaled output - I can't find it in the documentation.

Eddie B.

It appears that [initially_blank] does not work with %ga. A work-around is to avoid %ga and to do the ganging manually by attaching a call-back function to the two radio buttons and using them to set mode(1) and mode(2) directly.

To get the dpi for your printer you can use the Windows API function called GetDeviceCaps. You will find it in win32api.ins and the appropriate indexes (perhaps LOGPIXELSX and LOGPIXELSY) can be obtained from the Intenet and Microsoft Developer (MSDN) site.

You will also need the HDC for the printer. If your printer is the default printer then you can use the undocumented ClearWin+ routine called OPEN_DEFAULT_PRINTER_DC@ which can be found in clearwin.ins. The problem is that it has the wrong C name in this file. It should be '__open_default_printer_dc' (not '__open_default_printer_dc_at').

The code will look something like this...

iHDC = OPEN_DEFAULT_PRINT_DC@() ixdpi = GetDeviceCaps(iHDC, LOGPIXELSX) iydpi = GetDeviceCaps(iHDC, LOGPIXELSY)

This is just a guess but you may be able to work out the rest for yourself.

A better way to do the scaling is to use get_graphical_resolution@ as illustrated in the following sample....

  winapp

c------------------------------------------------------------------- integer i,winio@ external start_cb

  i=winio@('%ww%ca[Printing]&')    
  i=winio@('%mn[&Exit]&','EXIT')
  i=winio@('%`gr[BLACK]&',640,480,1)
  i=winio@('%sc',start_cb)
  end

c---------------------------------------------------------------------- integer function start_cb()
include <clearwin.ins> integer i,res,gr_han,pr_han integer height,screen_width,printer_width real*8 prf
gr_han=1 pr_han=2

  call graphics(1.0D0)

  call get_graphical_resolution@(screen_width,height)

  if(open_printer@(pr_han).ne.0) then
    call get_graphical_resolution@(printer_width,height)

c Open metafile for printer information i=open_metafile@(pr_han) prf=DBLE(printer_width)/screen_width call graphics(prf) i=close_metafile@(pr_han) c Make copies of the page, close_printer@ will do one copy anyway. i=do_copies@(pr_han,clearwin_info@('printer_copies')-1) res=close_printer@(pr_han) endif start_cb=1 end
c---------------------------------------------------------------------- subroutine graphics(prf) real8 prf integer2 x(10),y(10),err,hstar c Create a star x(1)=250prf
y(1)=200prf x(2)=400prf y(2)=350prf x(3)=350prf
y(3)=100prf x(4)=300prf
y(4)=350prf x(5)=450prf
y(5)=200prf x(6)=x(1) y(6)=y(1) call create_polygon@(x,y,6,hstar,err) call fill_polygon@(hstar,13,err) c Free memory call delete_polygon_definition@(hstar,err) end

Thank you for the effort you have gone to to give me two replies ... I think what I really needed was in the first one. I had pretty much got the hang of printing something, but my problem was getting an exact scale. I'm writing a code to replace a DOS code written in MS Fortran (16 bit) about 16 or 17 yrs ago, which writes to a Roland A3 plotter. The commands for the plotter are simple, explicit, and in 1/10 mm steps. It plots a chunk of survey that must be exactly 1/500 scale (or whatever is specified). The plotter hangs off the printer port. My students now turn their noses up at anything that isn't Windows. My DOS program hates running in a DOS box, because the output is no longer 'input a reading, see the result plot out' (it is buffered in some way) - and I used ANSI screen ESCape codes, which don't seem to be supported in an XP DOS box - and which look vaguely prehistoric now. I've re-written the whole lot be proper Windows - but now I find that the A3 plotters are on their last legs, can't be repaired easily! So I'm trying to get the graphics to come out on an A3 printer. It seemed to me that the resolution could be set by a user at print time, and going from 300 dpi to 600 dpi would flip the real scale from 1/500 to 1/1000 - Windows doesn't seem to operate with scales as I understand them, i.e. 1mm on the paper actually means something, like 1 metre, or 1 ton etc! Just drawing all the data to an arbitrary scale on screen or printer, seems easy - but who wants a map at 1/13,212.5 scale, when the whole point of the exercise is for them to be able to overlay their work on that of another student group, and see the 'fit'?

I was relieved to hear that my problem with the last initially_blank %rf box wasn't my fault. I may simply put the ganged radio buttons 'earlier' in the window, which also seems to cure matters.

Is there a special command to get a 'splash screen' on startup (like when Plato starts?).

Regards

Eddie B.

For a splash box you need something like this...

WINAPP ...... i=winio@('%ww[no_border,no_caption,no_maxminbox,topmost]&') i=winio@(%^bm[SPLASHBMP]&','EXIT') i=winio@(%dl%lw',2.0D0,'EXIT',ictrl) ..... RESOURCES SPLASHBMP BITMAP 'bitmapfile.bmp'

That darn last %rf[initially_blank] box still clears itself. I changed the first ganged radio button set to 'un-ganged', with a separate call back function for each button ... can I have parameters to a call back function? It isn't clear .... anyway, there are 3 call backs, all addressing the control variables (which are in COMON). Nope, that last %rf[initially_blank] box still clears when the radio buttons are changed. I had two sets of 3 ganged buttons, so I put individual call backs on the members of the second set as well. Once again, the last darn %rf box clears itself.

If the %rf box isn't [initially_blank] it doesn't clear (as, for example, when I'm going back and forth through existing data). It's only when I reach the stage of entering new data - where I want the boxes initially empty - that this happens.

I've come to the conclusion that it is a 'feature' of Clearwin. Surely I'm not the first to discover it.

Thanks for the info on the initial 'splash'. It's clever.

Regards

Eddie B.

Eddie

I far as I am aware you are the first to report this behaviour. [initially_blank] is a fairly recent feature and %ga may not be widely used.

I still think that the answer is to avoid using %ga and to create the 'radio button' effect directly...

WINAPP integer i,winio@,c1,c2,i1,i2 common i1,i2 external c1,c2 i1 = 1 i2 = 0 i=winio@('%^rb[Radio One]&',i1,c1) i=winio@('%2nl&') i=winio@('%^rb[Radio Two]',i2,c2) end

integer function c1() common i1,i2 if(i1 == 1) i2 = 0 c1 = 1
end

integer function c2() common i1,i2 if(i2 == 1) i1 = 0 c2 = 1 end

Hi Paul,

I've already done that, and it doesn't work. It's identical with the %ga ganged radio buttons, or with radio buttons with Fortran-encoded ganging. I think that the problem is with the %rf[initially_blank] .... (do you want some code?)

Regarding the _AT which shouldn't be on the C function ... there are several declarations with _AT at the end of the function name in CLEARWIN.INS ... are they all wrong?

Best regards

Eddie B

You can post some code if you wish. Mine is below. An initial check with the other _AT declarations indicates that the others are OK.

WINAPP integer i,winio@,c1,c2,i1,i2 common i1,i2 external c1,c2 i1 = 1 i2 = 0 i=winio@('%rd[initially_blank]&',i) i=winio@('%2nl&') i=winio@('%rd[initially_blank]&',j) i=winio@('%2nl&') i=winio@('%^rb[Radio One]&',i1,c1) i=winio@('%2nl&') i=winio@('%^rb[Radio Two]',i2,c2) end

integer function c1() common i1,i2 if(i1 == 1) i2 = 0 c1 = 1
end

integer function c2() common i1,i2 if(i2 == 1) i1 = 0 c2 = 1 end

Paul,

You've done the code with %rd[initially_blank] ... and that isn't a problem. It's %rf[initially_blank] that is the problem.

    WINAPP  300000,500000
    OPTIONS (INTL)

C PROGRAM ABC IMPLICIT DOUBLE PRECISION (A-H, O-Z) INTEGER MODE(3) INCLUDE <WINDOWS.INS> MODE(1)=1 MODE(2)=0 MODE(3)=0 IA=WINIO@('%ca[Data entry screen]&') IA=WINIO@('Real variable%2ta%rf[INITIALLY_BLANK]&', R) IA=WINIO@('%nl%nl%ob[named_l][mode]%nl%3ga&', + MODE(1), MODE(2), MODE(3)) IA=WINIO@('%rb[RB 1]&', MODE(1)) IA=WINIO@('%nl%nl%rb[RB 2]&', MODE(2)) IA=WINIO@('%nl%nl%rb[RB 3]&', MODE(3)) IA=WINIO@('%nl%nl%cb&') IA=WINIO@('%5nl%cn%6bt[&Quit]') WRITE(1,*) R, MODE

    STOP
    END

The above code is the simple demonstrator. What is put into the %rd box doesn't stay there if you use the radio buttons. This one has 3 ganged buttons. Below, based on your original advice, is the demonstrator with 2 radio buttons ganged by the call back functions:

    WINAPP  300000,500000
    OPTIONS (INTL)

C PROGRAM ABC IMPLICIT DOUBLE PRECISION (A-H, O-Z) INTEGER MODE(2) COMMON MODE INCLUDE <WINDOWS.INS> EXTERNAL N1, N2 MODE(1)=1 MODE(2)=0 IA=WINIO@('%ca[Data entry screen]&') IA=WINIO@('Real variable%2ta%rf[INITIALLY_BLANK]&', R) IA=WINIO@('%nl%nl%ob[named_l][mode]%nl&') IA=WINIO@('%^rb[RB 1]&', MODE(1),N1) IA=WINIO@('%nl%nl%^rb[RB 2]&', MODE(2),N2) IA=WINIO@('%nl%nl%cb&') IA=WINIO@('%5nl%cn%6`bt[&Quit]') WRITE(1,*) R, MODE

    STOP
    END

    INTEGER FUNCTION N1()
    INTEGER MODE(2)
    COMMON MODE
    MODE(1)=1
    MODE(2)=0
    N1=1
    RETURN   
    END

    INTEGER FUNCTION N2()
    INTEGER MODE(2)
    COMMON MODE
    MODE(1)=0
    MODE(2)=1
    N2=1
    RETURN   
    END

If you put a value in the %rf box, it gets wiped when you change the radio button selector. This does not happen with %rd boxes, as your demo shows. It doesn't hapen with %rf boxes if they aren't [initially_blank].

Yours

Eddie B

It's getting to me now. I said %rd (above) ... when I meant %rf. The problem is with %rf, not with %rd!

I've had several attempts at fixes. The most effective is to put all the ganged radio buttons first, and the data entry %rd and %rf boxes last, so that the problem occurs less frequently simply because the user selects the correct radio button first. I have found that it isn't just the last %rf[initially_blank] box that clears, but all of them that have data put in them.

Eddie B.

Here is a work-around for you to try...

logical L double precision x i=winio@('%rf&',x) i=winio@('%lc&,ih) i=winio@('%lw',ic) L=SetWindowText(ih,''C)

SetWindowText requires an INCLUDE. %sc with callback is an alternative to %lw.

Assuming that ''C is a null-terminated zero length string (as neither FTN77 nor 95 seem to like what I've typed, so I've substituted CHAR(0) - which at least compiles. I've also tried ' '//char(0)), then a by product of trying this is that my PC goes haywire, opens loadsa windows, and is a swine to reboot!

I did take the precaution of looking up both of the %l? codes to see what they actually do, and decided that they were harmless, even though I didn't understand the rationale of what was being attempted.

SetWindowText is in WIN32API.INS, by the way, so is found in INCLUDE <WINDOWS.INS>

I may just give up ..... fortunately, in my application, the use of [initially_blank] is purely cosmetic anyway

Eddie

Eddie

I thought that I would return the favour and offer my tanner's worth (that should confuse the youngster's !)

Instead of using %rf to display a floating point number try displaying a character string with %rs that has been intialised with spaces, the character string can then be easily read to obtain the floating point number with a free format read statement when necessary.

John 😮

John,

Nice one. I used to do that with ESCape codes - first VT52 (nice on the dear old Apricot), and later VT100 (ANSI - and horrible in comparison). That required inspecting every keystroke. Must be age, but it never occurred to me to do the same with Clearwin! I'm also going to try with setting limits on the values entered. In the particular instance where it has trapped me, a zero isn't a valid entry, but it doesn't cause a crash (because it is multiplied, not divided by), and one can always go back and edit it ... at that point, the box isn't [initially_blank] and Clearwin does what it says on the tin. I'm thinking of adding a button with a voice clip to save the effort of cursing ... just one mouse click and it's done. Now where's the control to make the volume increase every time the E&xpletive! button is pressed?

Thanks for the advice - I will take it.

Eddie

If your compiler will not accept ''C then you must use ' ' (i.e. a single space without the C at the end).

I hope to fix the bug before too long but it probably won't be before the next release.

This bug has now been fixed and the fix will be in the next release.

So what was it? Probably far too complex and abstruse for me to understand, but yet fixable with a line of code. These things usually are. Thanks for looking at it.

Eddie