/CHECK_WINIO and other compile messages

Paul, thought it might be better to have a different thread for /CHECK_WINIO.

One thing I did find 'confusing' (could be just me): when arguments have been swapped, specifically when a callback and variable are swapped. The error message given when this occurs is (example) 'error 1222 - Argument number 2 (ABCD) of WINIO@ should be a 32 bit integer'.

The text of the 1222 message could be made clearer i.e. 'Argument number 2 (ABCD) of WINIO@ should be a 32 bit integer function'., identifying the type of the argument that should be present.

It is exceptionally nice to have the argument position and variable name defined explicitly! It really helps.

The error message for a LOGICAL (or REAL*4) in the wrong place (error 140) is explicit, but does not identify the variable or its position in the argument. This error is not dependent on /CHECK_WINIO, which is nice because compilation can continue. But for complex winio@() calls, it can take a while to figure things out.

Bill,

My suggestion is don't have complicated WINIO@ calls. It makes life so much simpler if they are short, even if it makes subprograms longer.

A good subset of rules is:

(a) Only one input box per WINIO@, although all the stuff like %ill, %bg etc can go with it. (b) A run of format codes that are simply positioning can go in a single WINIO@ (like %ff%2nl%cn etc) with no parameters of callbacks (c) Simplify %mn and toolbar creation statements (d) For the main window creation, separate the parts into different subroutines, e.g. one for menus, one for the toolbar, one for startup and close down, one for the client area etc. (e) Use inline comments every fifth WINIO@ continuation so you can count them easily. Also use inline comments to match %ob and %cb. (f) Minimise the number of callback functions in any one WINIO@ call.

Eddie

Bill

Again I am confused. The following code...

program main
integer iw,winio@
iw = winio@('%^bt[OK]',iw)
end 

gives

',iw) end

gives

[quote:c1bae57a12]error 1222 - Argument number 2 (IW) of WINIO@ should be a call-back function

Bill

The behaviour for REAL*4 has already been improved.

The following code...

program main
integer iw,winio@
real x
iw = winio@('%rf',x)
end 

will give

error 140 - WINIO@ cannot process REAL(KIND=1) argument X, only CHARACTER, INTEGER(3) or REAL(2)

Paul, thanks this will be an improvement at the next version. Looking forward to it!

Paul, sorry; should have posted the sample code for the error.

	use mswin
    	integer,external:: abcd
        integer:: defg
        i = winio@('%^rd',abcd,defg)
	end

yields

ForumTesting.F95(4) : error 1222 - Argument number 2 (ABCD) of WINIO@ should be a 32 bit integer

The compiler does not know the relationship between the format string for winio@ and its arguments but if you use /CHECK_WINIO then it will call into the ClearWin+ library (DLL) in order to attempt a check. But this is not always possible particularly when the outcome depends on the runtime order of a sequence of winio@ calls.

You can put the format string into a dynamically constructed CHARACTER variable or call ClearWin+ functions that stack up the arguments before calling winio@. In these cases the compiler does not have a chance.

I may exaggerate a bit or use not precise wording about diagnostics messages but hopefully not too much. Though i was a fan of tough at English slang UK tech site TheInquirer for two+ decades, my own vocabulary have not progressed due to lack of practice with my penguins. OK, to me this wording of error is good

ForumTesting.F95(4) : error 1222 - Argument number 2 (ABCD) of WINIO@ should be a 32 bit integer

adding also at the end 'or INTEGER(N)' (few people know but i don't what the N is here. But with this message we will finally know). When in rare and hence definitely confusing cases the 32/64bit integers are needed depending on 32/64 compiler, the message should tell to use universal INTEGER (7) specifically set for that purpose

And i agree with John that the warning should be more specific, which is in 99% compiler capable doing. But even his suggestion

error 149 - For Format '%rf' argument X is declared as xxxxx when it should be real(2)

requires translation in tired and confused programmer's brain. Better would be

error 149 - For Format '%rf' argument X is declared as xxxxx when it should be REAL(2) or DOUBLE PRECISION

Was there any legitimate reason to start calling double precision as REAL(2) ? If there is no any chance to feed Clearwin+ controls with any other own programmer-made precision besides REAL*8 then why the heck to follow Fortran Standard's recommendations which are actually just confusing people with their REAL(1), REAL(2), REAL(3), INTEGER (2), INTEGER (3) names which tell person nothing. And there also CHARACTER added to this glorious universal Clearwin error message -- all this just confuses poor programmer to the boiling point 😃 Have i told that i learned English not so elitist urban dictionary mostly trying programming Clearwin GUIs? Now all looks nice and cool, but i can imagine what novices feel.