Will the real select_graphics_object@ please stand up?

Aaaarggh - this sort of thing does my head in. After a couple of genuinely minor changes to my code (change of location of a couple of variable declarations), and a build, and even a last resort rebuild, I was suddenly being told (three times) at link time:

WARNING - Module component SELECT_GRAPHICS_OBJECT@ has been defined differently here than previously in object file blah

I have been rebuilding this code many times a day for about three months now, and I never got this warning until today. Needless to say, none of the minor changes I made most recently involved any lines using select_graphics_object@ 😃 (although I did comment out one such line yesterday).

(I have been getting this warning - WARNING the following symbols are missing: MODULE CLRWIN - every time I do a /CHECKMATE or a /DEBUG, but not a /RELEASE, build every time, but I've given up mentioning this. Until now).

So I searched for every use of select_graphics_object@ in my code. Every single use is of the form 'call select_graphics_object@ (h)'. Nothing defined differently to anything else, as it were.

So I hit the help file - where I found that select_graphics_object@ is in fact an integer function and not a subroutine. Apparently. At this point, a faint bell started to ring, and I hit the forum, with a vague recollection of having tripped over this before. If so, it must have been a long time ago, because I can't find a forum post on the subject. There are not many posts that mention select_graphics_object@, but use as both a subroutine and an integer function is in evidence (sometimes within the same thread :roll: ).

So I changed all my 'call's to 'i ='s and lo, SLINK is happy again.

I deduce that select_graphics_object@ has probably changed its status from a subroutine to an integer function at some point.

But what I really want to know is, given that my code had no less than 11 different lines that use select_graphics_object@ as a subroutine, why have I been getting away with it several times a day for three months, and what did I do that suddenly alerted the linker to something that - to be fair - should be blatantly obvious?

Sparge,

Just a guess, but maybe your error message turned up because of implicit typing of variable names, which would see SELECT_etc as REAL, not INTEGER. If you are a disciple of the IMPLICIT NONE religion, forgetting that in one routine can wreak havoc, but surreptitious havoc, as implicit typing takes over.

Amazing that in FTN95 one can often invoke a function as a subroutine and maybe vice versa without too much problem at first. Naively, I would expect the stack to get out of order. Perhaps it does, but in a way that may not matter.

It's a bit like USE_RGB_COLOURS@ which can be done with 1 or .TRUE. - but then, they are the same thing as far as the PC is concerned!

Your automatic use of a CALL for this type of subprogram shows a classical education in Fortran. McCracken would never have allowed integer functions to be used in this way, and as for a callback function - it would have shuffled his card deck!

On a serious note, why can a callback function be declared in an EXTERNAL statement without its name also being declared to be INTEGER and still work?

Eddie

Hi Eddie,

Oooh, IMPLICIT_NONE ... that's an interesting idea. I am indeed a disciple of the IMPLICIT NONE religion. Indeed, it is so axiomatic in my modus operandi that make sure I never forget it by having it as one of only two settings in my FTN95 configuration file (the oher being /WINDOWS). So it gets hardwired into everything I do. I never forget because I don't have to remember 😉

And yet I just had a look in Plato under project properties and found a 'Set global IMPLICIT_NONE' checkbox that is unchecked ... I wonder if the NONE in the config file IMPLICIT_NONE is not as global a NONE as I think it is? Or is it possble that the Plato left hand is not as fully informed about the FTN95 right hand's activity as it could be? I may have to investigate that sometime if I get bored. Still doesn't explain why the linker suddenly got sniffy though, after roughly 1000 builds when it was quite happy, I don't think.

Classical, yes, I suppose so. But not so classical that I know who McCracken is or was, but I like the sound of the cut of his or her jib, and shall do a bit of homework. I have no idea how to invoke 'this type of subprogram' any other way. Can one just omit the CALL keyword (as per C, I believe)?

On the serious note, it is now so long since I typed the EXTERNAL keyword that I am unable to contribute meaningfully (particularly since I never really understood what it meant or why it was necessary at the time).

Hi Sparge,

By 'this type' I meant a subprogram that is not PURE, and has side effects (which is the point of a callback, and SELECT_GRAPHICS_OBJECT@). McCracken was the main author of numerous self-instruction books on Fortran in the distant past. Students borrowed and did not return my copies of some of them, so I can't check. But my recollection is that he would have been dead against FUNCTIONs with side effects, and I'm sure I never heard of a FUNCTION being so daring as to not only be IMPURE, but also to return an error code, from McCracken or anyone else.

EXTERNAL is (inter alia) a way of letting on to a compiler that a given symbolic name is a subprogram when it isn't obvious from context, e.g. when it appears as an argument in a subprogram call without its own argument list or parentheses. I know that you can do the same with CONTAINS or with an INTERFACE, but with EXTERNAL your callback functions can more easily reside in a different source file, and the scoping rules for everything in Fortran-77 are much simpler than in Fortran-90.

I never saw the point of EXTERNAL prior to using Clearwin, and most cases it was recommended for seem to me easier to do in another way. More to the point, it is also used as a way of telling the compiler that you want to use the symbolic name of an intrinsic function for your own purposes (now that'll 'do your head in'). It used to be recommended as a way of nodding to the linker that a named BLOCK DATA subprogram should be searched for, but that may well have been compiler-specific.

In languages that are explicitly IMPLICIT NONE (like the Algol-60 I used to use), there is no implicit typing to fall back on: no declaration and an error always occurs. However, as Fortran falls back on implicit typing if the IMPLICIT NONE is not given, there's always the chance that it turns itself off somewhere, somehow.

Error rates in PC components are so low that commonly we imagine errors never happen. However a low probability doesn't mean never, it means that sooner or later a bit will flip. Maybe you got zonked by a cosmic ray in chez Sparge, or possibly your machine is beginning to pack up. If it was mine, I'd be far more convinced by the suggestion that I had inadvertently changed a setting or forgotten something, while all the while hoping that it was time for that new machine I've been promising myself but am too mean to buy.

How did you get on with the Windows User Experience Guidelines? They made me think very hard about the OK button, and don't they make your applications look shabby and old-fashioned? (And I'm not talking about my programming style here, that McCracken would have recognised and possibly approved of).

Eddie