%ob does not like wide multi-monitors

%ob[status,thin_panelled] crashes the code when i open window 2900 pixels wide (stretched over two monitors). Tells the window is too wide. Can this be fixed in future releases?

        i=winio@('%nl%ob[status,thin_panelled]&')
        i=winio@('%20st %20st&', MouseClReason_Mouse_Pos, MouseClReason_Mouse_Pos5)       
        i=winio@('%cb&')

Hi Dan,

Is this something that can be fixed with SUBROUTINE SET_MAXIMUM_DIALOG_SIZE@( WIDTH, HEIGHT )?

Regards

Eddie

Yes, i think this is a solution, thanks, Eddie. But, strange.... i think i compiled it ones successfully and it worked. Then abruptly whatever i do i get the 'Error 29 Call to missing routine SET_MAXIMUM_DIALOG_SIZE# ...' Devilry 😦

Dan, I'm a bit confused ... you finished the routine name with @ or # ?

I never had any problem maximising a main window across dual monitors, but a dialog - that's a new trick

Eddie

Yeah, I've noticed that, it seems to replace @ with # in the diagnostic. The missing routine is usually caused by omitting the ' include <windows.ins>' or the 'Use' equivalent from the calling routine. Ian

I 'use mswin'. Adding 'use clearwin' is redundant, and even if i add, it does not change anything -- i get same error that subroutine SET_MAXIMUM_DIALOG_SIZE@ is missing. Actually, i do not see this subroutine anywhere in the package (only in chm and enh files), and i have latest version. Where is it? Did i already say 'devilry'? 😃 that 's the word you will pronounce zillion times learning and using Clearwin+. It moved there from FTN90 and early FTN95... LOL

And that error is own compiler diagnostics message which replaces @ with #, and adds underscore. That just confuses programmer, i think this should be fixed.

The interface is

      C_EXTERNAL SET_MAX_DIALOG_SIZE@ '__set_max_dialog_size' (VAL, VAL)

and can be found in clearwin.ins for example.

True devilry....now my search engine finds what before did not...i see it is there in clearwin MOD and ins files. Still when run i get the same error complaining about missing routine....Some older MOD file in the path which does not have this subroutine? Impossible

Just put the interface line into your code with the other declarations - in the subprogram where the routine is called.

hahaha....i found the error. Machine finds it in no time, but humans are too complex for that. Easy to make such error and hard to find. Guess where it is ? Will not post the answer for a while, just for fun, may be someone will find it.

hint: you have all needed information to find the reason. Devilry !

OK. Do we tell when we see it?

Sorry chaps, I'm a little confused. It appears that the well known quotation 'Britain and America, two countries divided by a common language' is being displayed to the extreme in this forum. To steal a phrase from Monty Python - 'Sorry, don't understand your banter old chap, cabbage crates coming over the briny' etc.

What I find more interesting is that I have successfully opened windows with a menu bar, toolbar and a %gr graphics area spanning 2 screens without the slightest problem, so I thought that the size limit for dialog boxes was fixed/increased - until I saw Dan's post, and the lightbulb came on.

Once again, the documentation is correct, but not sufficient for a user to pre-empt problems, no matter how much reading he does.

C'mon Dan, I 'tipped you the wink' (Brit) so 'give us a clue' (Brit).

Eddie

The name of the routine is SET_MAX_DIALOG_SIZE@ and not SET_MAXIMUM_DIALOG_SIZE@. This is not revealed by IMPLICIT NONE but should by shown up by using /DCLVAR on the command line.

Yep. Humans tent to think that MAX and MAXIMUM are short and long form of same thing. LOL

Thanks all again.

Paul, I think /DCLVAR would be great thing to add to switches in all my codes. The more diagnostics the better. But when I've tried /DCLVAR it gives diagnostics on subroutines like that 1051) call ColorBarInitPar *** COLORBARINITPAR must have the EXTERNAL attribute when /DCLVAR is used

Aha! I see it now. If only I hadn't been too lazy to retype the routine name, and hadn't just cut'n'pasted it from FTN95.CHM ...

Eddie

/DCLVAR requires that you declare all subprograms when they are called.

I have corrected FTN95.chm.

Is declaring subroutines as external legal portable standard Fortran?

/dclvar is like an extension to /implicit_none. I have tried to adopt this as a coding convention to document all variables and called routines, but without using /dclvar, I have not consistently updated my EXTERNAL declarations. Adopting /dclvar could enforce this convention. There is a question as to how using EXTERNAL as a documention of routines used conforms to the standard, but it can assist as a documentation of the code when returning to update. Are warnings provided for both undeclared routines and declared routines that are not used ? The use of EXTERNAL for documenting routines being used may conflict with the use of clearwin.ins, where the external declaration is in the include file. (not sure of this)

John

EXTERNAL is included in the Fortran standard.

Warnings are only provided (with /DCLVAR) for undeclared routines otherwise there would be a problem with INCLUDE statements for standard libraries.