%rf

Is there a way (in, say, %9rf format) to have the output data in G (E) format starting with the numbers greater then say 1000 or 10000 ? I get the numbers which is impossible to comprehend like 1496235697.16. Currently only after numbers greater then 10 billion the F format in %rf output changes to E

No, unless it is read only in which case you could try %wf.

You might be able to do your own formatting in a callback function. I would have to think about how that would be done.

Or may be logically would be better just to make say in

i=winio@('%10.4wf',result)

variable result dynamically updatable when we call

call window_update@(result) ? Same for %wd, %ws...

If the result only changes in the code and is not an input value provided by the end user then the task becomes simpler.

%wd etc are static controls that are fixed when the window is created so they are designed for constant values.

As you can see, there are three types of values (constant, programmable and user input). Which of these are you looking at?

Well, i use %rf, %rd and %rs (with window_update@) to display dynamically for example (x,y) of the cursor in the graphics window or results of the simulation in realtime. But %wf, %wd and %ws do not update their output value

Since cursor position and results of simulations are the output, not input, the common sense and the intuition interpreting letters r as read and w as write tells me to use %wf, %wd and %ws ...but oops. Year later I again forget this and scratch the head why not?

May be for output of constants it would be better to use some other letters, but i suspect there are no more close in resembplance of world 'write'.

/* By the way Clearwin from its start should use 3 letters or users definable words. Two letters names are too cryptic (like short variable names or passwords which are not better to memorize, longer ones are actually simpler. I use 31 and even longer byte variable names. BTW, i found also that some Linus source code subroutines are written with very long variables and the source immediately becomes self-documented)

For formatted output I would consider using an internal Fortran WRITE statement (i.e. WRITE to a character variable) together with %`rs (and %co for a surrounding box).

Good workaround, thanks, Paul

Dan,

Anything that doesn't update itself probably needs a call to UPDATE_WINDOW@ (variable) when it changes.

Eddie

Eddie, No, the black science behind this is that window_update@ does not work with %wd, %wf and %ws by design. There could be deepdeep reasons for that but i do not see them. As a result i do output into %rd, %rf, and %rs. The %wf does while the %rf does not do conversion of floating point numbers the way user wants it - you can not tell it to write with format E10.3 or G9.2

Paul, unfortunately the attempts with workaround using internal write failed with access violation by the reasons we discussed some time ago - running long simulation code is doing its own output (into %cw text window or any other output) while the user at the same time hovering with the mouse over graphics window which reads mouse position and performs internal write trying to make another text output (does not matter that this is another window containing graphics screen).

I've made one more workaround step back then making fake internal write a la encode/decode but this time i will try different ways (using possibly lock/unlock when will have time unless will get other more portable suggestions.

I suppose the next thing I would try would be to write a C function calling sprintf but you may not be up for this.

Puzzled how this C function is doing its job - is it just formatting f.p. output (like DECs encode/decode) without printing or actually making print on logical unit or using internal write (and if so how it will not cause the access violation too?)

I am just guessing that sprintf is different from an internal Fortran WRITE which has certain limitations and hence a little more prone to failure.