forums.silverfrost.com

DanRRight · Posted: Sun Sep 22, 2024 2:16 am Post subject: Birth defect of Clearwin

There exist few design problems of Clearwin annoying from its start. Here is one of them:

Sometimes not human readable numbers.

Any chance to fix these unbearable F-formatted 12345678546665456 numbers and make them human readable in E format like 1.23456E+18 ?

PaulLaidler · Posted: Sun Sep 22, 2024 6:26 am Post subject:

See for example item 421 in cwplus.enh.

Kenneth_Smith · Posted: Sun Sep 22, 2024 4:32 pm Post subject:

DanRRight · Posted: Mon Sep 23, 2024 7:14 am Post subject:

Cool, that good upgrade. The only problem i am getting an error

Kenneth_Smith · Posted: Mon Sep 23, 2024 2:15 pm Post subject:

Dan, I don't think that's unreasonable, since the value may be changed by the user and the displayed value needs to "reformatted".

DanRRight · Posted: Tue Sep 24, 2024 6:05 am Post subject:

Convince me why controlling focus loss it is obligatory and why i will die without it. Typically i never use focus monitor. Before when i used it it only produced me troubles and in early times of Clearwin crashes

Also I see the length of control changes. In my example above all of them initially at 18, 12 and 6 character length became at the end of the same length. When i wrote

i = winio@('a = %18rf[fmt=0.4e]%nl&',a)

declaring it 18 characters long that was done for the purpose of formatting of GUI. Otherwise the controls will be jumping in size with changing declarations in the E format ruining GUI alignment. That would be permissible if i declared the %RF control too short for the E format to be able to write the number correctly, then i'd agree the length could be modified by the code (because generating an error to crash GUI is unacceptable)

PaulLaidler · Posted: Tue Sep 24, 2024 6:43 am Post subject:

In general when a user types in a fp number it will contain digits, possible full stop, signs and E or e. Only when they have finished can ClearWin+ read and then present the number in the requested format.

The %co option effectly says "read the number when the user changes to a different control".

Maybe ClearWin+ could do "better" in cases where E and e are not permitted but otherwise to read and present as the number is typed character by character seems too much.

But if the Clearwin+ programmer knows exactly what they want then they can use a callback function to filter the input character by character.

DanRRight · Posted: Tue Sep 24, 2024 8:50 am Post subject:

Can you guys rewrite complaining demo code above to show how it was intended to work by design? Potential advantages of this approach (or unavoidable obstacles) kind of do not cross my quick view. I do not understand why you like it.
May be it is not that bad as i understood how it works. I have 100000 %RF used mostly both for reading and writing simultaneously and adding too much more to this operation would be way too cumbersomish. Clearwin was good because it was comparable and even surpassing in simplicity and convenience to plain Fortran WRITE(*,*) var

PaulLaidler · Posted: Sat Sep 28, 2024 10:57 am Post subject:

DanRRight · Posted: Sun Sep 29, 2024 7:18 pm Post subject:

This is exactly what was needed!
Thanks Paul

Was it well advertised in Silverfrost own channels? I do not have Help for FTN95 temporally, it does not work by some reason in WINE (very old version probably) under Linux and can not see visual examples like this below. KBase would be good place i think instead of digging deep into Clearwin..enh

And it correctly makes fields sizes too. Adding one %CO per file (not per each %RF as i initially thought) would be not as cumbersome (if Clearwin will remind about $CO was missing Would be totally awesome) The source was this