soccer jersey forums.silverfrost.com :: View topic - /CHECK_WINIO and other compile messages
forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

/CHECK_WINIO and other compile messages

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions
View previous topic :: View next topic  
Author Message
wahorger



Joined: 13 Oct 2014
Posts: 1226
Location: Morrison, CO, USA

PostPosted: Thu Jul 11, 2019 2:03 pm    Post subject: /CHECK_WINIO and other compile messages Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2393
Location: Yateley, Hants, UK

PostPosted: Thu Jul 11, 2019 3:06 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8016
Location: Salford, UK

PostPosted: Thu Jul 11, 2019 3:48 pm    Post subject: Reply with quote

Bill

Again I am confused. The following code...

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


gives

Quote:
error 1222 - Argument number 2 (IW) of WINIO@ should be a call-back function
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8016
Location: Salford, UK

PostPosted: Thu Jul 11, 2019 3:58 pm    Post subject: Reply with quote

Bill

The behaviour for REAL*4 has already been improved.

The following code...

Code:
program main
integer iw,winio@
real x
iw = winio@("%rf",x)
end


will give

Quote:
error 140 - WINIO@ cannot process REAL(KIND=1) argument X, only CHARACTER, INTEGER(3) or REAL(2)
Back to top
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 1226
Location: Morrison, CO, USA

PostPosted: Sat Jul 13, 2019 6:12 am    Post subject: Reply with quote

Paul, thanks this will be an improvement at the next version. Looking forward to it!
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 1226
Location: Morrison, CO, USA

PostPosted: Sat Jul 13, 2019 6:15 am    Post subject: Reply with quote

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

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


yields

Quote:

ForumTesting.F95(4) : error 1222 - Argument number 2 (ABCD) of WINIO@ should be a 32 bit integer
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8016
Location: Salford, UK

PostPosted: Thu Jul 18, 2019 7:50 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2865
Location: South Pole, Antarctica

PostPosted: Thu Jul 18, 2019 12:34 pm    Post subject: Re: Reply with quote

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
Quote:

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
Quote:

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
Quote:

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 Smile 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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group