forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Off limits %~fl warning
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7160
Location: Salford, UK

PostPosted: Wed May 12, 2021 7:11 pm    Post subject: Reply with quote

It would be about 150 lines.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7160
Location: Salford, UK

PostPosted: Thu May 13, 2021 12:41 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
Kenneth_Smith



Joined: 18 May 2012
Posts: 506
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Thu May 13, 2021 9:37 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 1012
Location: Morrison, CO, USA

PostPosted: Fri May 14, 2021 12:27 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
DanRRight



Joined: 10 Mar 2008
Posts: 2479
Location: South Pole, Antarctica

PostPosted: Fri May 14, 2021 5:56 am    Post subject: Reply with quote

Code:
winapp
program main
real*8 A
integer (7) ilc_backgr
common /aaaa/A, ilc_backgr
integer, external :: Run

 a=0.1
 ilc_backgr  = 0
 i=winio@('%rf%lc&', A, ilc_backgr)
 i=winio@('%ff%^bt[Change A]%es', Run)

end

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

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

if(a.gt.1) then
      iColBkg=rgb@(255,133,155)
      call set_control_back_colour@(ilc_backgr, iColBkg)
else
      iColBkg=rgb@(255,255,255)
      call set_control_back_colour@(ilc_backgr, iColBkg)
endif

 Run = 2
end function


This is how i currently make warnings. Even preparing this smallest demo i spent 30 minutes searching for the bug. You will 1000 times forget to declare integer (7) ilc_backgr i guarantee you ! Smile

Compare that with just one tilde added
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 1012
Location: Morrison, CO, USA

PostPosted: Fri May 14, 2021 3:14 pm    Post subject: Reply with quote

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.

Code:
   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]
Back to top
View user's profile Send private message Visit poster's website
DanRRight



Joined: 10 Mar 2008
Posts: 2479
Location: South Pole, Antarctica

PostPosted: Fri May 14, 2021 10:23 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 1012
Location: Morrison, CO, USA

PostPosted: Fri May 14, 2021 11:02 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7160
Location: Salford, UK

PostPosted: Sat May 15, 2021 11:50 am    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2479
Location: South Pole, Antarctica

PostPosted: Sat May 15, 2021 4:58 pm    Post subject: Reply with quote

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 Smile

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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7160
Location: Salford, UK

PostPosted: Sat May 15, 2021 9:50 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2479
Location: South Pole, Antarctica

PostPosted: Sat May 15, 2021 11:22 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7160
Location: Salford, UK

PostPosted: Tue May 18, 2021 1:16 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2479
Location: South Pole, Antarctica

PostPosted: Tue May 18, 2021 5:17 pm    Post subject: Reply with quote

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 ?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7160
Location: Salford, UK

PostPosted: Tue May 18, 2021 6:30 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group