Concept help

[Alex Rice]

On Feb 17, 2004, at 6:08 PM, Thomas McGrath III wrote:
> Only the storage and retrieval of multiple items seems complicated 
> especially since there seems to be a couple of different ways to go 
> about it and I don't know the ins and outs of each to make a proper 
> educated decision on the issue.

I'm not really sure what the requirements are- because you are not 
being very specific with examples (and probably aren't allowed to) 
That's OK though. Here are some ideas:

First idea)

Kind of like what Dar just now suggested. Use custom properties to save 
the allowed button states as a "hashtable" or "dictionary".

-- if button 37 is clicked then:
put the uButtonDownState[ 37 ] of this stack into tState
-- tState could contain data like buttonNum=state,buttonNum=state, ...
-- 1=disabled,2=hidden,3=enabled,4=visible,..., etc.
repeat for each item tItem of tState
  split tItem by "="
  switch tItem[2]
	case "disabled"
		disable button item[1]
		break
	case "visible"
		show button item[1]
	...
  ...
end repeat

Second idea)

If there are many logical connections between many buttons then you are 
talking about a many-to-many pattern matching problem. You will know it 
when you have an explosion of if-then rules in trying to program the 
rules of the system. I don't know if this is the problem in your 
system. If it is, a rule based expert system like CLIPS is perfect 
because it has a pattern matching engine than efficiently handles 
many-to-many problems.

For example you could have a great number of rules like the following, 
and CLIPS could always efficiently find the correct state of the 
system.

(defrule button-dependency-n

	(button (num 1) (depressed TRUE))
	(button (num 2) (visible TRUE))
	(button (num 3) (visible FALSE))
	(button (num 4) (depressed FALSE))
	?button <- (button (num 5) (visible FALSE))

	=>

	(modify ?button (visible TRUE))
)

The above CLIPS rule states in English: "If button 1 is depressed, 
button 2 is visible, button 3 is hidden, button 4 is not depressed, and 
button 5 is hidden, then button 5 should be made visible".

Note that changing the state of button 5 could have many dependencies, 
and if so, other rules would fire consequently- CLIPS handles the 
"activation agenda" (You don't need to check for dependencies yourself 
that's what the CLIPS pattern matching engine does)

In the above example, the changing button 5 would result in a partial 
activation of the following rule button-dependency-n2.  If button 7 
were depressed, then there would be a full activation and the rule 
would fire:

(defrule button-dependency-n2

	(button (num 5) (visible TRUE))
	(button (num 7) (depressed TRUE))
	
	=>
	
	(printout t "bingo!")
)

Note that a CLIPS rule is merely an IF-THEN statement. The form is
(defrule rule-name
...IF...
=>
...THEN ...)

IF = LHS = left hand side of the rule
THEN = RHS = right hand side of the rule.

In procedural programming (Transcript, Basic, C, whatever) you would 
have to test each of the If-thens, 1 at a time, which can be extremely 
slow. Using CLIPS the procedural part the IF-THEN statement is 
eliminated so the CLIPS engine instantaneously fires the rules that 
match the current state of the system. Hope this helps give you some 
ideas.

See also <http://mindlube.com/developer/revclips/>


--
Alex Rice | Mindlube Software | http://mindlube.com