forums.silverfrost.com

[PaulLaidler]

It would be about 150 lines.

[PaulLaidler]

Dan

I have investigated this issue with the aim of providing an alternative to control_update@ or an additional %rf option. At the moment I can't find a way to do this. It looks like it would require a new format code as an alternative to %rf.

[Kenneth_Smith]

In situations like this I would add a �Check data� button to the Clearwin+ window. The associated call back can then pop up a window displaying an error message, such as �parameter X� out of range. In addition the call back can also do a sense check on combinations of input parameters.

For example if two parameters such as the reactance X (series inductance) and susceptance B (shunt capacitance) for an overhead power transmission line are entered, I would check that these are greater than zero, and also check that in combination they don�t generate a velocity of wave propagation greater than the speed of light. Similarly for XLPE insulated power cables, due to the higher capacitance I would expect the parameters to give a velocity of wave propagation of around 60% the speed of light.

This can catch lots of data entry errors (more than %~fl can do) before any subsequent analysis is undertaken. Even if the user does not perform the manual data check, the call back can be the first routine called by the analysis subprogram so preventing needless computations � so it serves two purposes, without any difficult programming.

[wahorger]

What I have been doing is to highlight the control that is "out of range" to let the user know they need to take action. I don't change the control (value or text), just highlight it. I have about 50 variables of all types (float, integer, text) that have their own criterion for "good" or "not good".

Also, I do use the %fl/%il to apply limits that cannot be exceeded, like the altitude of a drill hole (core) cannot be greater that 28,000 feet, not less than -2000 feet (below sea level). But I signal that something is wrong if drilling is done at greater than 89.9 degrees (upward?).

I enjoyed reading Paul's code; and there are other ways to do the same thing. Granted, each variable that is to be limit checked may have its own set of parameter/WINIO@() commands. That said, if one has a hundred parameters, it is likely that they are initialized/created from an array, making the limits to be applied easier to specify, also with arrays.

I like using a %ud and passing a pointer to a TYPE or array that becomes "attached" to the control and thus always usable. The callback uses that array/TYPE to determine the goodness of the user input. One set of routines applied "globally" to limit check different data types and different control types.

[DanRRight]

[wahorger]

Making the assumption that the limit check needs to be performed due to user input, the following code will do that, and allows tailoring for each double.

The function limit_check_double() does the work, and can be applied anywhere %fl would have been used. As implemented here, it will not change the variable, only flag it's value when changed. In my code where this is used, the initial color is set when the window is being built. I did not do that here.

Not saying that what you do is incorrect, just that there are other ways.

[DanRRight]

Bill,
For a few variables this is practical but not for hundreds. And tomorrow you will forget how it was done and every time will need to refresh this in your memory...

With this probably would be good to ask Paul to replicate functionality of warning into new controls like %iw/%fw (w - for warning, i don't remember in a snap, may be such combinations of letters is already taken).

Or may be besides tilde just use sign plus or minus %-il/%-fl and it will do the same as %~il/%~fl but not restricting variable in the code, just warn whatever way. Even better, then my first example in this thread will also work

Just one symbol will do the trick

[wahorger]

DanRRight,

I agree that for hundreds of variables all with the same limits, the %il/%fl solution is preferable. Faced with that situation, I would use the %il/%fl solution!

For me, I document what I've done so I don't forget about what I am doing and how I did it, and what limitations it has. I have a number of these code snippets that I use all over my main product because it is easier than recreating a routine to handle one situation, then replicating that code when another variable needs similar treatment. And, it makes testing easier, which I dearly love! And, as I get older, I am glad I documented the code!

It is strictly a matter of utility and style. My style is to keep everything as data driven as possible without using COMMON or MODULE. I only go "programmatically driven" when the data solution isn't appropriate (special processing or multiple disparate data types).

I find data tables built on user-defined TYPE's to be especially useful! And, when using ALLOCATE, easy to manage.

[PaulLaidler]

Dan

I can now see how to add an extra routine to do what you want but I have a question relating to a detail about what this routine should do...

After ClearWin+ has processed an out-of-range value received via a programmed routine, the value shown on screen will be corrected and an alert icon displayed, but should ClearWin+ correct the source variable or not?

ClearWin+ has the address of the source variable and for user changes (from the keyboard) the value at this address is automatically corrected when out of range. Should this be the same for changes via a programmed routine?

[DanRRight]

Paul,

It is good to have also not correcting variable option. I see Bill and Ken also doing that but each of us our own tricky ways

I thought that my first demo in this thread does not work (red dot does not appear) because %fl corrects the value and after correction it does not violate the limits anymore. I understood that making red dot to appear in this case was tricky

But if you will introduce what i called %-rf the correction of values will not be needed and the warning sign will appear. This will be kind of soft warning that the limits are violated but this is now user's discretion to fix that if needed

To distinguish %~rf and %-rf may be different color warnings have to be introduced, say red and orange

[PaulLaidler]

Dan

I would like you state your peference. My question is, do you choose (a) or (b) where

(a) ClearWin+ corrects the program variable or

(b) ClearWin+ does not correct the program variable.

[DanRRight]

Ideally, both

%~fl corrects variables. If i understood you correctly that you now have found the way to show warning sign in all my demo codes above - that would be great.

With %-fl better not correct the variable, just show it as is, plus to make the warning of a bit different color than %~fl when out of limits

[PaulLaidler]

The next release of ClearWin+ will have new %co options as follows.

New options have been added to %co in order to provide alternatives to the default action for %~il and %~fl when an out-of-range value is either
a) provided by a user keyboard edit or b) provided by a programmed update to the associated variable (e.g. together with a call to window_update@).

The default action for user edit is: error icon shown, display is not corrected, associated variable is corrected.
The default action for programmed update is: no icon is shown, display is corrected, associated variable is not corrected.

The new options allow for any combination of:
%co[warn_on_edit] changes the error icon for a user edit to a warning icon.
%co[alert_on_update] changes from no icon to an error icon for a programmed update.
%co[warn_on_update] implies [alert_on_update] but changes the error icon to a warning icon.
%co[limit_on_update] implies [alert_on_update] but causes the associated variable to be corrected.

In addition a grave accent can now be used so that %`co restores the default state for all of its options.

[DanRRight]

Paul,
Always great to hear about new options.

If this is an altrernative way, then am i right that with %co variable will not be corrected manually or programmatically? Correction of variable manually or programmatically is already done with %fl. Or %co will be broader action control which will include %~fl functionality also ?

[PaulLaidler]

Dan

The new options only work for %~fl and %~il.

Try adding them to your simple program.

A new set of DLLs is available in the usual place.