forums.silverfrost.com

PaulLaidler · Posted: Thu Feb 08, 2018 4:17 pm Post subject:

The simple and direct way is to call the Windows API ShowWindow.

DanRRight · Posted: Thu Feb 08, 2018 8:48 pm Post subject:

Cool, will play with this option too. Thanks, Paul

PaulLaidler · Posted: Tue May 22, 2018 7:50 am Post subject:

Dan

A bug has been identified in the ClearWin+ code for %ps and this is likely to be the cause of the failure. I will post a message when a new set of DLLs becomes available. I can do this soon as long as it is understood that there will be no significant changes for %pl and %fr.

DanRRight · Posted: Wed May 23, 2018 11:34 pm Post subject:

This was the most annoying bug in Clearwin, true devilry. "Was", if it really was catched, I cross my fingers. What could be more bad then to have the bug which disappears when you start the program inside the debugger?

It disappears in debugger even if you compile the code with /nocheck , so this is how I used the code for more then a decade, always running it via debugger. And this is how I discovered that besides of this error the debugger is actually very very useful.

DanRRight · Posted: Fri May 25, 2018 6:58 am Post subject:

Of course for this exact problem debugger did not find the bug, it was hiding it out at least I was able to run the code

DanRRight · Posted: Sun Jan 31, 2021 6:31 am Post subject:

Here is shortest version of crash of property sheet. This could be not the same as in my large code where property sheet crashes but it still crashes and it should never do that no matter what. Of course i can make it not crashing by the tricks but the point is not to hide but to find this very deeply hidden reason for the crashes.
Hints:
1) If you add SAVE statement it does not crash (my larger code still crashes). Same if you compile it with /SAVE it does not crash (but again my larger code still crashes. The only way to make my larger code not to crash is to run it via SDBG even if it compiled with /NOCHECK and /OPTIMIZE. This does not influences its speed but creates an obvious inconvenience to always use SDBG)
2) If you remove kpol6 and associated %rd it does not crash
3) if you compile it with the /check it will inform that you forgot to define some values. Behavior though is the same like with or without kpol6
4) if you substitute one line in main program with another (uses button to call property sheet) it does not crash
5) If you compile my larger code with /undef it does not reveal any problems still it crashes. So the problem is most probably inside the property sheet source code

Code is in the next post

/* Didn't I mention before that anyone who is not using property sheet is losing a lot and their programs most probably look like sh#t and are barely usable?

DanRRight · Posted: Sun Jan 31, 2021 6:32 am Post subject:

CONTINUE from previous page.

COMPILING: FTN95 aaa.f95 /link or FTN95 aaa.f95 /link /check

JohnCampbell · Joined: 16 Feb 2006 Posts: 2587 Location: Sydney

Dan,

Your example is beyond my comprehension, especially with the selection of accelerator keys.
I am finding that by changing to the following I am changing the response. Basically I declared all the variables used in the table as static (save) in the module. (I could/should have also given them an initial value?)
You have these variables dynamic and so re-allocated on the stack for each call to MainSettings, with no initialisation. Does this make sense ?

DanRRight · Posted: Sun Jan 31, 2021 8:11 am Post subject:

John,

Thanks for trying. Please confirm that my code crashes with your set of compiler/computers.

If i initialize all kpol variables the %PS does not crash but the point is that something will always will be not initialized, some elements of arrays for example, when your property sheet will become super large. And it will crash.

For example I do not know what is not initialized in my larger code, everything is checked many times in decade, but one of my property sheets crashes 100% if not run via SDGB. I do not know what specifically SDBG may do with the code compiled with /nocheck but it 100% prevents property sheet from crashing - this is good hint for SF to check. I hope SF will somehow make some traps for the attempts of %PS to crash.

Clearwin code has never crash no matter what the error. For example OpenGL was made such a way that it never crashes. It may not plot anything if something is wrong, arrays violated, request to plot requires too much time and resources to complete etc, it will leave the screen black so you will be able to retry the plot but it will never crash

My 1 year old version of Clearwin still not always checks for all cases of uninitialized variables (can not install newest version because a lot of programs are permanently running), for example it does not check for SIZEINCRFORZ1 above. It might not check for some other cases and looks like %PS is sensitive to uninitialized stuff it handles

The " 'set', lwCtrlSettingsMain, 0 " is similar to "EXIT" if you use %lw. I often use %lw in my codes to allow them to continue their run like nothing happened while you open property sheet and do something in it in parallel. Otherwise without %lw when you open property sheet the code run will stop and wait till you exit it. The %lw is useful in many other situations, for example when the warning will pop to inform you about something without stopping the code. You will close the warning window when necessary, or it will close itself or fade away after some time you define

JohnCampbell · Joined: 16 Feb 2006 Posts: 2587 Location: Sydney

Dan,

Not sure what crash is ?

With your code, when I go to file>settings>debug I get:
"A variable for %rd has not been given an initial value.
Do you want to continue? Click No to abort."

I select Yes and do this 5 or 6 times and get to the menu.
repeating the process sees the modified values lost, which confirms my suspicions.

(not sure if this version has kpol6 listed, as kpol6 is required for my modified code.)

Also my default compile initially falied, as I have /implicit_none in ftn95.cfg but compiled as ftn95 aa2.f90 /link /check /-imp ( This suggested the problem I identified)

There may be other problems I am not identifying ?

With the modified module, the program appeared to run as required.
( so not /64 and integer(7) problems )

Kenneth_Smith · Posted: Sun Jan 31, 2021 11:28 am Post subject:

Dan, I replicated your crash with 11 sheets. Removing the 11th sheet from the code and the crash is eliminated. I wonder if there may perhaps be a maximum of 10 permitted sheets with the coding of the DLL? Paul may have a view on that.
Ken

mecej4 · Joined: 31 Oct 2006 Posts: 1897

I compiled and linked Dan's code using FTN95 8.70 with /opt /p6. I then ran the resulting program, then clicked on File->Settings; in the new tabbed window that popped up, I clicked the radio-button Selection->PrintScreen Density, then Ok.

At this point I received an Access Violation window, "The instruction at address 00000000 attempted to read from location 00000000".

I then repeated all the steps above, but with /64 instead of /p6. The resulting EXE did not crash this time.

LitusSaxonicum · Posted: Sun Jan 31, 2021 11:24 pm Post subject:

DanRRight · Posted: Mon Feb 01, 2021 12:15 am Post subject:

Thank you all for trying.

Updated compiler and the %PS still crashes.

Eddie, the key words were "most probably". Of course you can recreate similar functionality and/or adopt it to fit specific device better and even make it look more modern, but even if it crashes in some cases (i have dozens working OK and one only can crash if i forgot to call it via workaround) the %PS is still so great that i can not live without it. Besides i found bearable workarounds till it will be fixed. I'd find more if it was really needed.
I'd even stress that almost no one with large codes can live without it and have manageable code. Recreation of similar functionality in house in such cases will not worth efforts. Also Microsoft and Paul slowly but steadily update look and feel of CWP. You also can do that so it will not look any boring or dated. As to crashing - Paul will fix it eventually. And will make new bugs possibly even in your workarounds Smile