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 repeatSecond 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
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
