Opening second window while still creating the current one

Suppose you are creating CWP window and in the middle of all that numerous calls to WINIO@ you load some file but loading by some reason failing. So to inform user about that you create another small CWP Warning window to tell what is happening.

The problem is that during the run you will get an error that the second %ca is not permitted or %sy must be before other controls are made. OK, you remove %ca and %sy from second window but then second window gets incorporated into body of first window instead of being independent

Basically, is it possible to create another independent window before you completed creating first?

One way would be to use the Windows API....

stdcall MessageBox 'MessageBoxA'(VAL,STRING,STRING,VAL):integer
integer,parameter::MB_ICONEXCLAMATION=Z'30'
i = MessageBox(0,'Failure message...','Caption',MB_ICONEXCLAMATION)

Thanks Paul, that will help.

I'm posting crude demo example for others to take a look too. Here are two functions, if you chose

i=SomeFaultyFunction()

then you'll get the error as i described it above which emulates that the code tried to open Window 2 with the warning that something was wrong. If you instead will take this function

i=SomeFaultyFunction2()

then you'll get Paul's workaround.

   integer  SomeFaultyFunction, SomeFaultyFunction2
   external SomeFaultyFunction, SomeFaultyFunction2

   i=winio@('%ww%ca[Window 1]&')
   i=winio@(' Temperature %ta%rd%ff&',iT) 

   i=SomeFaultyFunction2()

   i=winio@(' Density [g/cm3]%ta%rd%ff&',iD) 
   i=winio@('%ac[esc]','exit')
   end
!........................................
   integer function SomeFaultyFunction()    
   i=winio@('%ww%ca[Window 2]&')
   i=winio@('%si! Error Occured during reading file aaaaa.dat %ff&')
   i=winio@('%cn%bt[OK]%ac[esc]','exit')
   SomeFaultyFunction=1
   end function

!........................................
   integer function SomeFaultyFunction2()    
   stdcall MessageBox 'MessageBoxA'(VAL,STRING,STRING,VAL):integer 
   integer,parameter::MB_ICONEXCLAMATION=Z'30'
   i = MessageBox(0,'Failure message...','Caption',MB_ICONEXCLAMATION)
   SomeFaultyFunction2=1
   end function

As a related question, or suggestion -- wouldn't it be possible to implement in future CWP that it treats every call to %ww as signal to create the new window? Now %ww just gives some options and can be used many times. The need to open another window while first is not yet finished should be very common in complex GUIs and the warnings may need to contain a lot of information but it will be hard to do that with WinAPI calls. (Users which are unfamiliar with the code can do a hell of unimaginable stupid things and when you program you need to make huge amount of fool-proof workarounds and help messages to guide them). Such extension of CWP looks to me as very natural and logical approach, but i do not know how hard it will be to implement something like that

Dan

I am not sure that I fully understand what you are asking for but I am fairly confident that it would require a fundamental design of winio@. As it is the design is quite 'clever' and to create a working Window and then add more components would be more complex and fundamentally differ in design.

ClearWin+ does allow you to change and add some attribute on the fly but you can not add more controls after the the window has been formed (i.e. ClearWin+ could not do this for you without major reworking of the code).

Having said this, the new format code %nw currently allows you to change or add menus after the window has been formed and there may be ways to extend %nw in the future.

Dan,

Why are you (say) opening a file before the main window is fully opened? Ordinarily, you open an existing file in response to the File>Open menu command, OR by drag and drop into the client area, OR in response to a command line argument (e.g. user clicked on a file with an association to your program. All of these can be dealt with after the window has been finalised, in callbacks to (a) %mn[File[Open]], (b) %dr and (c) %sc.

If your main window appearance depends on what is in the datafile, then why not finalise the window in a basic way, open the datafile, then if necessary you could redraw a new main window and close the old one behind it. Having the main window finalised - as you discovered - makes it easy to open a new dialog (window), but difficult to open the dialog before another window is finalised. Of course, you could launch a completely separate program with START_PROCESS@ or START_PPROCESS@, and that could open its own Clearwin+ window(s) - if you want to make the old window inaccessible, then you could overwrite the whole screen with a white area in SUPER_MAXIMISED mode (client area alone shows), using the SET_OPACITY routine someone posted in this forum a few years ago, then write over the top with your error handling window, or you could use FREEZE_WINDOW_CONTENTS@ for a similar effect.

Good luck!

Eddie

Thanks for suggestions Eddie and Paul again. With time i became so deeply stuck in CWP that now when build something it's not just one-two parameters is inherited from some other place but the whole working subroutines/functions. Of course these subroutines have their own bug handling also written in CWP because of CWP is also great exactly for that. The programs are large and i often even do not remember what is there and if it will conflict with something or not

In this case when i was making new CWP window with graphics i 'borrowed' graphics code from another part of the same large program together with all its files, settings and bug reports. It's like kind of attempt of object oriented programming in my still Neanderthal world. Graphics subroutine's own initial parameters intended to influence the current window settings. After many tries and faults i found a place to call graphics subroutine and all is great but when error happens, the graphics subroutine calls additional CWP windows and that windows are messing the whole idea up.

Perhaps it was possible as Eddie suggests to gather all the information before building new window ( i have done that but something was not exactly as needed, you know, that happens when too much is there). So i ended up calling graphics code in the middle of new window. Also this was more intuitive -- to use subroutine in exactly when it will be used because improves readability of spaghetti code...

I expect that this will be not a rear accidental case but the rule when people will use CWP extensively. So was my suggestion that each window must start with %ww (right now we can even omit %ww, it is not obligatory) and if you wrote few lines lower one more %ww then older code interrupts and treats all following text as an insert for the new window until it ends, after which creating of older window continues. It's like DO loop inside another DO loop.

Dan,

I sympathise with your problem. I to am struggeling to remember what I wrote years ago. I have fairly extensive libraries of numerical and file handling procedures. We need to review what we do and create libraries of graphics tools. It is a shame that modern programming appears to have discouraged the use of static libraries, as a stable library of routines is very useful.

John

The window starts being built with the first winio@ call. I used to think it started with %ca, but it doesn't, and it also doesn't start with %ww or %sy.

I suppose what Dan is asking for is %sn (I made that up! %sw is also available) Start a New window independent of anything else.

You never need a 'finish window building' format code, because 'no continuation' does that.

Eddie

Yes, Eddie, you are probably right, all what just needed is that exactly new control or new option to %ww[new_window]

John, I will never make an ideal graphics library, so damn much is there. But i can post here few screenshots as examples of what was achieved. The ideal graphics library, i'm convinced, must be made completely with OpenGL or similar by the professionals who write computer games

Graphics library? Most of what I want to draw is easily done with the Clearwin+ primitives. In my 'wish list' I have a few more, but they are like icing on an already elaborate cake. I'm impressed with OpenGL shading, but usually, if I want a fancy graphics I capture the images from my program and touch them up in CorelDraw. If I really want elaborate details in every run, then I predraw them and import them as images.

Clearwin+ does fonts well.

Eddie

Eddie, Yes, CWP has all needed for that. Of course the icing on the cake is not always needed, but i'm talking about general purpose graphics library, even more, the ideal graphics library. Almost all graphics libraries known so far to fortraneers are not supported dead stuff. My explanation? They ALL look like $!#&. Contrary, the Matlab graphics, for example, is ultimately simple but powerful and looks nice to be used even on the cover of Nature journal. The graphics output of our codes must look ready for journals without uploading raw data to external professional scientific graphics software. Like this for example

http://memg.ocean.dal.ca/fennel/SpecTop2011/Matlab_Logo.png

Similarly, if GUI looks cool and appealing, the developer himself is not tired to spend years and years by 100 hours/week on it. When too bored staring at the same spot for 30+ years I'd like sometimes to see this style of GUIs in my Windows programs (from YouTube) :

http://youtu.be/FqPswU1X32o