forums.silverfrost.com

wahorger · Joined: 13 Oct 2014 Posts: 1225 Location: Morrison, CO, USA

If this was answered in another earlier post, I apologize. I can't seem to find it.
---------------------
In porting my code to 64-bit, this is one of the items that didn't "port well".

After my code starts, I create a %cw inside of my main window so appropriate status messages can show up. The existing code just won't do it.

The code is:

DanRRight · Posted: Tue Mar 05, 2024 1:07 am Post subject:

Bill,
Try unit = 0 in %cw change to 1 if what is not working is related to messages made by Print* or WRITE(*,*). I do not know why this change was ever made recently which makes this not compatible with the entire world. Will FTN95 soon beat the entire world? Then it's ok Smile

But only then

wahorger · Joined: 13 Oct 2014 Posts: 1225 Location: Morrison, CO, USA

Dan,

Yeah, tried that already. No dice.

Bill

DanRRight · Posted: Tue Mar 05, 2024 2:08 am Post subject:

Here is a piece i took out my code

wahorger · Joined: 13 Oct 2014 Posts: 1225 Location: Morrison, CO, USA

Dan, thanks for that.

Still, using UNIT=1 for the attachment to %cw as a child window isn't working. I'll have to look into a different solution, perhaps using your basic code, to see what I can do.

Bill

PaulLaidler · Posted: Tue Mar 05, 2024 8:08 am Post subject:

Bill

At first sight I don't think that you have supplied enough code for me to work out what is not working.

I would need a small working program using all of the required routines.

wahorger · Joined: 13 Oct 2014 Posts: 1225 Location: Morrison, CO, USA

I have figured out what is apparently going on with this, and I think it's all me. That said, I'm hoping that within the 64-bit framework, I can duplicate what I have.

For my users, I send status messages to the embedded %cw window. At the same time, these messages (and those below the "display" threshold) go to a logging file that maintains a running commentary about what the user has selected, how that selection was processed, etc.

I wrote a special driver that takes the character strings and sends them to stdout and/or the logging file. The logging file is opened in "C". Output in "C" is the only output you can use within a special driver.

In 32-bit, FORTRAN unit 1 and the "C" standard output unit (stdout) happen to be "the same", meaning that within "C", if you send a string of characters to "stdout", it goes the same place as FORTRAN unit 1. So, messages being directed to be written to Fortran unit 1 OR through "C" get displayed on the %cw window.

In 64-bit, that linkage is different.

Now, anything written to stdout goes to the DOS command window, not to Fortran unit 1 which has been attached (maybe?) to the %cw. This includes "PRINT *" statements that do not use the special driver.

So, I'm still experimenting with %cw redirection, but am not confident I can duplicate what happens in 32-bit in this new environment.

wahorger · Joined: 13 Oct 2014 Posts: 1225 Location: Morrison, CO, USA

So, in the documentation, if you link with /WINDOWS as an option, you'll not get the console opening up. That's good. Still working on the sequence of operations to get the standard output to the right %cw placement in my window. If you have any comments or tricks to help let me know.

I think the problem is that my initialization (i.e. reading a configuration file and resulting statements to output) might be pulling the re-direction away from my window because my window hasn't been fully created yet. And 32-bit and 64-bit might differ in the way the standard output gets "assigned" to a window anyway.