Off limits %~fl warning

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.

	winapp
	program main
	real*8 A,a_limit(2)
	data a_limit/0.d0,1.d0/
	integer (7) ilc_backgr
	integer, external :: limit_check_double,run
	
	a=0.1d0
	i=winio@('%^rf%ud&', A,limit_check_double,loc(a_limit)) ! attaches the limit array to the control
	i=winio@('%ff%^bt[Change A]%ud%es', Run,loc(a))
	
	end

	integer function limit_check_double()
	use mswin
	real*8,pointer:: a,a_limit(:)
	integer (7) variable,handle,user_data
	integer iColBkg
	variable	= clearwin_info@('LATEST_VARIABLE') ! address of 'A'
	handle		= clearwin_info@('CURRENT_CONTROL')
	user_data	= get_user_data@(handle) ! get the associated limit array address
	allocate(a,absolute_address=variable)
	allocate(a_limit(2),absolute_address=user_data)
	if(a.lt.a_limit(1).or.a.gt.a_limit(2)) then
		iColBkg=rgb@(255,133,155)
		call set_control_back_colour@(handle, iColBkg)
	else
		iColBkg=rgb@(255,255,255)
		call set_control_back_colour@(handle, iColBkg)
	endif
	call window_update@(a)
	limit_check_double = 2
	return
	end
	
	integer function Run()
	Run = 1
	return
	end function

[/code]

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

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.

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?

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

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.

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

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

1. 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.

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 ?

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.

Looks cool!

Please run this code below as an example

winapp
program main
real*8 A
common /aaaa/A
integer, external :: Run

 a=0.1

 i=winio@('%co[warn_on_update]%~fl%rf%`fl&', 0d0,1d0, A)
 i=winio@('%ff%^bt[Change A]%es', Run)

end

integer function Run()
include <windows.ins>
  real*8 A
  common /aaaa/A

  A = A + 1
  IF(A.GT.2) a=0.1
  call window_update@(A)

 Run = 2
end function

Is there similar option when the variable is not corrected and plotted as is? For example this code always shows variable not larger than 1 while in not corrected case the variable shown has to be 1.1

Or with current case at least let it be corrected but shown it has to be 1.1. The behavior of control has to mimic 1:1 the human manual action otherwise it will be confusing ! When human types 1.1 the warning pops up, human sees 1.1 in red but the code still sees 1. Same i think has to be with artificial intelligence inside the computer code, isn't it ? 😃 Why it should be different?

Otherwise if programmatically after clicking we see warning, the number displayed is 1.0, instead of 1.1 it becomes not clear why the warning appeared if all looks OK - the limits are not violated !

Dan

We may have gone full circle. Your latest request could be what you get when calling control_update@ without the new %co options.

Anyway I have now added one more option %co[stet_on_update] that has the desired effect. It keeps everything in one place and makes control_update@ redundant.

The new option will be included in the next release of the DLLs.

Paul,

Everything in one place is good solution. Eager to see what you have got.

When to use window_update@ and when control_update@ ?

Is among these options also not modifying variable (WYSIWYG) option ?

I, too, am curious about control_update@().

See item 456 in cwplus.enh and https://forums.silverfrost.com/Forum/Topic/3753&start=15 post dated November 21 2020.

You can probably use it with the new %co options but it would be better use the latest addition and wait for the next release of the DLLs.

Thanks for the references, Paul.

Look how great it notifies. Try not to notice among 1000 pieces of jumping information! I wasted so much of my own time and supercomputer time by not noticing some small parameters which were wrong. This was not 3 seconds but weeks and months. Thanks Paul for stet_on_update option ( i = winio('%co[stet_on_update]%~fl%8rf%fl%co&', overfill ). Before this would be shown as just the number 1 in black like all others and you would not notice it

Paul, Suggestion for possibly small correction. I like this stet_on_update very much. It saved me days, i do not do costly mistakes anymore when not notice some parameter is out of range

The only i suggest is to return to your first version of such bullets with smaller size of warnings signs like i photoshopped below. The one out of 4 plotted below near 1.052 looks aesthetically the best. Current ones are largest here, they often mess with the neighbor controls.

UPDATE: Even worse situation is with current large warning bullets is when the variable returns to allowed range. In this case only part of red cross disappears while approximately 1/3 of the tip of it remains orphaned because it belongs to the line before the current one

It should no be possible for 32x32 bit icons to appear in this context but I have removed them from the resource data so this ought to prevent it from happening in the future.