*** WINIO@ cannot process REAL(KIND=1) arguments, only .....

This is more like a suggestion/question/request. Sometimes controls have a lot, say, 20 of arguments, and when the error like the above occurs you always guess which one is wrong shuffling the large code back and forth to check if all 20 were declared properly.

Can the compiler tell exactly which argument it is not happy with? For his digital mind it is simpler then for our analog ones. He (well, it) probably can even fix the problem himself in no time asking you 'Want me add REAL*8 statement for ABC and also declare the FuncA as an external?' and you just answer 'Sure, go' 😃

(And on April 1 all compiler diagnostics messages must be misleading and humorous. 'You have got an integer underflow error on line 1223653...' 'Floating point overflow in character A10 format':-) Do that and this compiler will be #1 till year 3000.

Returning to my sheeps, so which damn argument out of 18 could be possibly wrong?)

I can have a look.

A good practice is to winio@ continuation. If a format code needs arguments then give it its own winio@.

Dan,

I agree with Paul. I modified your last example to better understand what you did. (Works like you reported) winapp use clrwin common i1,i2,i3, j1,j2,j3 integer i1,i2,i3, j1,j2,j3 integer cb, i external cb save ! i = winio@ ('%ww&') i = winio@ ('%ac[esc]&','exit') ! i = winio@ ('Add two numbers %ta%6^{rd&', i1,cb) i = winio@ (' + %6}rd&', i2,cb) i = winio@ (' = %6rd&', i3) i = winio@ ('%ff&') ! i = winio@ ('Add two numbers %ta%dd%4^{rd&', 1,j1,cb) i = winio@ (' + %dd%4}rd&', 1,j2,cb) i = winio@ (' = %6rd&', j3) i = winio@ ('%ff')

   end 

   integer function cb() 
   use clrwin 
   common    i1,i2,i3, j1,j2,j3 
   integer   i1,i2,i3, j1,j2,j3 
!
     i3=i1+i2 
     j3=j1+j2 
     call window_update@ (i3) 
     call window_update@ (j3) 
   cb=1 
   end function cb

John

That would increase our code length by 34734 lines LOL And make hell out of large codes readability because typically controls are combined to accomplish the same goal and are the reflection of the most convenient style of particular programmer. But for posting here i agree it is probably always worth adding some syntactic sugar. Yes, i know that my programming style is as bad as my English 😕

It has some advantages though. You probably remember that it comes from the concept expressed in this 1-line 132-character code

i=winio@('%ww%mi[i]%ca[win]%wp[a]%mn[File[Exit]]%th%dd%il%cn%`bg[yellow]%?7rd[index]%ff%nl%cn%^bm[e]%ff','exit',1,1,0,10,j,'exit') 
 end 

which looks like that

or the same without using any graphics resources

i=winio@('%ww%ca[CWP]%mn[File[Exit]]%th%dd%il%cn%`bg[yellow]%?7rd[index]%ff%nl%cn%tt[exit]%ff','exit',1,1,0,10,j)
end

Simpler way this will look like this (but this will not be simpler when already large source length explodes )

use clrwin
imlicit none
integer i
integer j
i=winio@('%ww&')
i=winio@('%mi[i]&')
i=winio@('%ca[win]&')
i=winio@('%wp[a]&')
i=winio@('%mn[File[Exit]]&','exit')
i=winio@('%th&')
i=winio@('%dd&',1)
i=winio@('%il&',1,0,10)
i=winio@('%cn&')
i=winio@('%`bg[yellow]&')
i=winio@('%?7rd[index]&',j)
i=winio@('%ff&')
i=winio@('%nl&')
i=winio@('%cn&')
i=winio@('%^bm[e]&')
i=winio@('%ff')
stop
end
 resources 
  a bitmap a.bmp  ! wallpaper
  e bitmap e.bmp  ! Exit button
  i icon   i.ico        ! icon

And when you program the GUI which have many controls in single line like here

you naturally tend to assemble them in the Fortran text similar way otherwise you will not find anything quick. That finalizes often as a dozen of variables in the single line with many continuation lines

Dan,

As your application program has multiple windows, presumably they all have common features that can be wrapped up in a subroutine, for example, as in:

      CALL WINDOW_SETUP (CAPTION_TEXT)

where

      SUBROUTINE WINDOW_SETUP (CAPTION_TEXT)
      INCLUDE <WINDOWS.INS>
      CHARACTER*(*) CAPTION_TEXT
      ... clearwin+ calls
      RETURN
      END

WINIO@ continuations can go across subroutine calls. This can save you a lot of lines.

When you specify a mimimise_icon with %mi you are also giving the window a system menu, which may bypass your attempts to make the window fixed size. The Windows standard is not to give this icon for modal windows (i.e. those that must be closed before the program continues).

Eddie

I would not use a new winio@ for every format code, only for those that have arguments.

Paul,

That was a helpful suggestion I have already decided to adopt in new code - certainly having multiple format codes requiring parameters make the WINIO@ rather complicated, as it is already difficult enough remembering (for example) where the grey-out code comes, let alone all the other options! Of course the shorter each statement is, the less and less need there is to approach column 72. Very few of my statements do, probably because if they get that far I know that they will be difficult to decipher 10, 20 or more years hence. My oldest code I use regularly is now 43 years old, and I have learnt a lot since then. One thing I am certain of is that I will not need to understand today's code in another 43 years ....

The one thing I forgot to say when recommending splitting Clearwin+ WINIO@ calls across subroutines is that they need to be explicitly SAVEd or there is a chance of the application crashing when closing down one or more windows: this is an application crash, not an FTN95/Clearwin+ crash, i.e. the system emits an appropriate message, but one that isn't helpful to a user who has just lost their work!

Eddie

Is it impossible to compiler to tell exactly which variable is of wrong type?

I have noted this as something to investigate.

I have had a look at this suggestion.

ClearWin+ error messages already provide the argument number of an unexpected argument.

Can you supply an example of an error condition where the argument number is not reported?

Paul,

I think Dan was hoping for the name of the variable!

I find it useful to keep track of what number continuation I am dealing with in several ways:

1. By dividing the WINIO@s for really complicated windows over a number of subroutines, as the error always gets the subroutine name for you

2. By having few parameters in WINIO@ invocations

3. By remembering to now and then put the continuation number in the code using an inline comment, e.g.

      IA=WINIO@('%si!Beware the Jaberwock, my son&') ! continuation 60
   

Eddie

I suppose that, in theory, it could be done! FTN95 could export a database that ClearWin+ could then access when an error occurs.