Newsletter #13: Jul/Aug/Sep 2003 Edition
Home Up Feedback Search

Products
Order
Downloads
Support
Articles & Tips
Recommended Links
About

 
 

 
 
RiverSoftAVG Newsletter #13
Jul/Aug/Sep 2003

 
Hello and welcome to Newsletter #13!  Another quarter, another late newsletter :-)  It's hard to believe but it has been almost exactly 3 years since we started writing these newsletters.  Hopefully, these newsletters have been as rewarding for you as they have been for us.  This issue, we have the usual news, tips, and downloads.  Also, we continue our optimizing expert system series to discuss optimizing fuzzy expert systems.  Enjoy yourself! 

A reminder, this newsletter and all previous ones are available for download from the web site at http://www.riversoftavg.com/articles_&_tips.htm


Contents

    Article: Optimizing Fuzzy Expert Systems
    News: Object Inspector Component Suite (OICS) is Now Available!
    Tip: Using the IECS with the OICS 
    Download: HelpScribble Apprentice Updated
    Download: Object Inspector Component Suite Demo Version
 
Note: You received this newsletter because you are an owner of a RiverSoftAVG product.  If you received this newsletter by mistake or if for any reason you wish to not receive any future mailings from RiverSoftAVG, just reply to this message informing us so.  We apologize for any intrusion.
 

Article: Optimizing Fuzzy Expert Systems

 
In the last edition, we discussed optimizing your expert systems (see http://www.riversoftavg.com/NewsLetters/newsletter2003AprMayJun.htm).  We took an example "traditional" expert system and managed to make it almost twice as fast using such ideas as control facts, reducing function calls, and sharing rule patterns.  At the time, we didn't talk about specific techniques for optimizing fuzzy expert systems.  In this article, we are going to specifically talk about techniques for optimizing fuzzy expert systems.  The techniques we investigated in the last article all still apply to fuzzy expert systems so be sure to read that article if you haven't already done so.
 
With fuzzy expert systems, you use fuzzy logic and fuzzy set theory to make your expert systems more intuitive and natural, with less rules, and with greater readability and maintainability. It also makes your systems more powerful by modelling problems hard to solve using traditional techniques.  As we have discussed in other newsletters (see http://riversoftavg.com/NewsLetters/newsletter2001JunJulAug.htm), Fuzzy Logic is a method for modeling and reasoning about imprecise or approximate concepts. Traditional logic, where concepts must be true or false, zero or one, has trouble at the boundaries of a problem: Is the water hot or cold? It's neither and both, it is somewhat hot. Fuzzy logic concerns itself with the boundaries of a concept, things can be "somewhat true" and "sorta false".
 
Do big optimizations first
 
Like traditional expert systems, the big gains in optimization come with working with the big picture.  Don't waste your time optimizing small parts of the expert system for small gains when you should be looking for the big gains.  We want to reduce the number of rules, the number of patterns, the number of fact templates, the number of facts, etc.  Fuzzy Expert Systems come with one obvious big picture optimization which reduces the number of rules in your expert systems: the Combs method.  The Combs method gives us big savings by reorganizing our expert system (another optimization tip from the last article).  Not only does the Combs method reduce the number of rules, it also reduces maintenance and enhances readability.   In Newsletter #7: Feb/Mar 2002 Edition, we discussed how to implement the Combs method in the IECS so we won't go into a lot of it here. 
 
The Combs method prevents the combinatorial explosion of fuzzy expert systems rules.  Combinatorial explosion of the number of rules occurs in Fuzzy Expert Systems as the number of dependent variables, or fuzzy variables, increase the variables values, or fuzzy sets, increase.  For example, suppose you have written a fuzzy expert system to determine the financial credit worthiness of an applicant.  Your first attempt at the fuzzy expert system uses two fuzzy variables: Income and Debt, both of which may be either Low, Medium, or High.  Your expert system also has one solution fuzzy variable: Risk.  Conventional thought for fuzzy expert systems is that you must write a rule for every combination of your dependent input variables: "if Income is Low and Debt is Low then Risk is Medium," "if Income is High and Debt is Low, then Risk is Low," etc.  You must create a rule for every combination of Income and Debt.  A Fuzzy Expert System designed this way is essentially what is called a Fuzzy Associative Memory, or FAM for your fuzzy system.  For two input variables (Income and Debt) and 3 fuzzy sets per variable (Low, Medium, High), you would need 3 squared or 9 rules.  If you added just one extra fuzzy set value to Income and Debt, you would need 4 squared (16) rules.  If you added another fuzzy variable, say Mental Health, you would now have 4 Cubed (4^3=64) rules.  As the number of fuzzy variables or fuzzy sets increase, the number of rules increases exponentially. 
 
William Combs developed a method to reduce this exponential growth to linear growth.  Instead of 10 Fuzzy Variables with 4 Fuzzy Sets Each having over a million rules, the Combs method makes you end up with 40 rules.  Instead of writing rules for every combination of input variables and fuzzy set values, you just write rules for each input variable by itself: "if Income is Low, then Risk is High", "if Income is Medium, then Risk is Medium", "if Income is High, then Risk is Low", etc.
 
Don't use fuzzy logic indiscriminately
 
The fuzzy logic in the IECS is more expensive in terms of memory footprint and processing time than "normal" facts and rules.  Do not use fuzzy logic indiscriminately.  It may seem obvious, but do not create a fuzzy expert system unless you gain by it, either in terms of correctness, simplicity, or some other benefit.  On a per rule basis, fuzzy rules always use more memory and take longer to pattern match.  The savings in fuzzy expert systems apply because you reduce the number of rules (not how fast they execute).  For example, our expert system from last time had a number of rules that stated "if number in some range, modify it by some amount."  If the modification had been complex or the range boundaries had been blurred, we may have been able to combine all of those rules into one fuzzy rule that made the modification based on the strength of the fuzzy pattern match (activation) of the rule.
 
For each expert system, you need to determine if a fuzzy expert system works for it.  Unfortunately, this can often take experimentation and prototyping.  But the results can be well worth it.
 
Investigate Rule Patterns
 
Even more than traditional expert systems, a fuzzy expert system can benefit from the tweaked use of rule patterns.  Fuzzy facts match with fuzzy rule patterns based on the maximum value in the intersection of the fuzzy fact with the fuzzy rule pattern fact. For example, the intersection (minimum) of very hot and somewhat warm could look like this:
 
Fuzzy Variable: Temperature
Fuzzy Values: [very hot] and [somewhat warm](+)
 
1.0000
0.9500
0.9000
0.8500
0.8000
0.7500
0.7000
0.6500                                       +++
0.6000                                          +
0.5500                                      +
0.5000                                           +
0.4500                                     +      +
0.4000
0.3500                                    +        +
0.3000                                              +
0.2500                                   +
0.2000                                  +            +
0.1500                                 +              +
0.1000
0.0500                              +++                +
0.0000++++++++++++++++++++++++++++++
    |----|----|----|----|----|----|----|----|----|----|
   0.00     20.00     40.00     60.00     80.00    100.00
 
Universe of Discourse: From 0.00 to 100.00
 
In this case, the maximum of the intersection is around 0.65. In fuzzy expert systems, this maximum, the pattern match strength is usually compared to some threshhold, if the strength is greater than the threshhold then the rule is activated and put on the agenda. This number also becomes the strength of the rule activation. But with fuzzy expert systems, if a rule has multiple patterns, the minimum of all the pattern match strengths determines if the rule is activated.  In the IECS, a fuzzy rule (a rule with at least one fuzzy pattern match) will activate if there is any match with a fact, as long as the strength of the activation stays above the fuzzy threshold (by default 0.01).  What this means in practice is that a fuzzy rule with many patterns may keep pattern matching much longer that you expect or want it to. 
 
Say we have a rule like this where three facts; age, income, and health; are all fuzzy facts:
 
(defrule r1
  (age old)
  (income high)
  (health low)
=>
...)
 
The IECS will match the age fact with the age pattern.  This is a relatively expensive operation where it will calculate the intersection fuzzy set, find the maximum of the intersection set, and then compare it to the threshold.  If it stays above the threshold, it will keep working and then match the income fact with the income pattern, etc.  This result will then modify any asserted fuzzy facts in the right hand side of the rule in a process called Fuzzy Correlation.  It can be advantageous to reorder your patterns to make the most restrictive match first so that the rest of the pattern matching is not performed.  This, of course, depends on which facts are changing most frequently, etc.
 
Ordering of rule patterns is even more when combining fuzzy facts and non-fuzzy facts
 
Fuzzy pattern matching is much more expensive than regular pattern matching.  A simple comparison operation (whether string, integer, or whatever) is much faster than the intersection set creation used with a fuzzy pattern match.  In general, it is preferable to have the non-fuzzy fact pattern matching earlier in the rule, unless the non-fuzzy facts are changing significantly more often than the fuzzy facts.  You can see significant savings by using this technique.  For example, suppose the pseudo rule above was modified to only execute if a name fact matched to Tom, Dick, or Harry.
 
(defrule r1
  (age old)
  (income high)
  (health low)
  (name ?name|Tom|Dick|Harry)
=>
...)
 
Even though all the rule patterns look similar, the knowledge that income, health, and age are fuzzy makes all the difference.  By putting the name pattern at the end, we require the IECS to do more work before possibly tossing out the result because the name is not Tom, Dick, or Harry.  This rule should result in a much faster expert system:
 
(defrule r1
  (name ?name|Tom|Dick|Harry)

  (age old)

  (income high)
  (health low)
=>
...)
 
This leads us to our next optimization...
 
Control Facts are good
 
Control facts, as we discussed last time, determine which rules get activated based on the value in the control fact.  The traditional idea is to have a "phase" control fact, which could have values of initialization, decision, action, etc.  Rules are written for a particular phase by putting the control fact in as a rule pattern:

(defrule control-fact-rule

    (phase initialization)

    (other-patterns)

    =>

)

Control facts in general should change less often than other facts.  Not only are control facts good for partitioning your expert system but they also can help the inference engine work less too, especially with fuzzy rules!

In the Tom, Dick, and Harry rule above, the name fact could possibly change much more often than the income, age, and health fuzzy facts.  That was the reason, we couldn't categorically state that it was better to have the name rule pattern at the beginning than the end.  Hopefully, a control fact would change much less often.  The control fact will help immensely in reducing the pattern matching work the IECS has to do.
 
Tweak the fuzzy threshold
 
All of this discussion about the IECS matching multiple fuzzy patterns until it falls below a threshold is begging to point out one little fact.  Perhaps, tweaking the threshold higher so that rule evaluation fails earlier can help the efficiency of your expert system.  Larger values (closer to 1) will make rules with multiple patterns fail much more easily.  This is a good thing and a bad thing. :-)  Good because the inference engine does less work, bad because rules that should execute don't execute.  You can tweak this threshold to see if it will work for you. 
 
The Little Optimizations
 
Fuzzy logic in the IECS is a powerful tool for making your expert systems simpler, more robust, and more powerful.  However, this power comes at a price.  The memory and processing requirements for a fuzzy expert system are higher than a traditional expert system.  The following tips for optimization are obvious after being exposed to them but may not have occured to you.  A traditional expert system may contain a temperature fact that contains one integer.  Rules would be written that match on that fact using simple constraints (equals, greater than, etc).  All very simple operations that do not take a lot of time.
 
However, fuzzy expert systems define a 2D array for a fuzzy variable.  Instead of assigning a simple integer temperature, fuzzy sets like "warm" or "cold" are defined.  These fuzzy sets use a 2D array of points

((x0 y0) (x1 y1)... (xN yN)) to define the shape of the term.  The more points you define for a shape, the more memory it consumes and the more processing time it takes to use that shape.  The next series of optimizations seek to reduce your memory and processing footprint.

 

Reduce the resolution of your fuzzy sets/shapes to the minimum needed

 

The IECS allows you to easily define fuzzy sets using some standard shape functions: pi, s, z, beta, and tri.  Except for the last one, all of these functions seek to balance precision (smoothness of the shape) with memory.  By default, the IECS uses 7 points to define a specialized fuzzy shape (controlled by the DefaultNumFunctionValues constant in FuzzyConsts.pas).  For example, the "warm" term for a fuzzy variable may be defined as a bell shaped curve (pi 50 25).  Such a shape would look like this:

 

Fuzzy Variable: TEMP

Fuzzy Values: (pi 50 25) (*)

 

1.0000                         *

0.9500                        * *

0.9000                       *   *

0.8500                      *     *

0.8000                     *       *

0.7500

0.7000

0.6500                    *         *

0.6000

0.5500                   *           *

0.5000

0.4500

0.4000                  *             *

0.3500

0.3000

0.2500                 *               *

0.2000                *                 *

0.1500               *                   *

0.1000              *                     *

0.0500             *                       *

0.0000*************                         ************

    |----|----|----|----|----|----|----|----|----|----|

   0.00     20.00     40.00     60.00     80.00    100.00

 

Universe of Discourse: From 0.00 to 100.00

 

When the IECS creates the bell curve using pi, it defines a 7x2 array: ((25.0000 0.0000) (33.3333 0.2222) (41.6667 0.7778) (50.0000 1.0000) (58.3333 0.7778) (66.6667 0.2222) (75.0000 0.0000) ).  However, in many case, you may not need such a smooth shape, a simple sawtooth shape using only three points may give good results:

 

Fuzzy Variable: TEMP

Fuzzy Values: (tri 25 50 75)(*)

 

1.0000                         *

0.9500

0.9000                        * *

0.8500                       *   *

0.8000

0.7500                      *     *

0.7000                     *       *

0.6500

0.6000                    *         *

0.5500

0.5000                   *           *

0.4500                  *             *

0.4000

0.3500                 *               *

0.3000                *                 *

0.2500

0.2000               *                   *

0.1500

0.1000              *                     *

0.0500             *                       *

0.0000*************                         ************

    |----|----|----|----|----|----|----|----|----|----|

   0.00     20.00     40.00     60.00     80.00    100.00

 

Universe of Discourse: From 0.00 to 100.00

 
You will have to see what will work in your fuzzy expert system.  If the results deviate too much from "acceptable" values, this optimization may not be for you.
 
Be careful with hedges as well.  The IECS provides an important class of fuzzy modifiers called hedges, e.g, "very", "about", "positively", etc.  Hedges modify the shape of a fuzzy set in predictable ways.  Hedges are very powerful because they are predictable as well as intuitive.  However, many of the hedges add points to work properly.  For example, the very hedge modifies a fuzzy set by pushing all values less than one towards zero.  This has the effect of shrinking the boundary, the fuzzy portion, of the set closer to the area that is completely in the set:
 

> (plot-fuzzy-value t *+ n n (create-fuzzy-value temperature (pi 50 30)) (create-fuzzy-value temperature very (pi 50 30)))

 

Fuzzy Variable: temperature

 

Fuzzy Values: (pi 50 30)(*) very [(pi 50 30)](+)

 

1.0000                         +

0.9500                        * *

0.9000                       *+ +*

0.8500                      *+   +*

0.8000                    **       **

0.7500                      +     +

0.7000                     +       +

0.6500                   *           *

0.6000                    +         +

0.5500                  *             *

0.5000                   +           +

0.4500                 *               *

0.4000                  +             +

0.3500                *                 *

0.3000

0.2500                 +               +

0.2000              **                   **

0.1500             *  +                 +  *

0.1000            *                         *

0.0500           * +++                   +++ *

0.0000+++++++++++++                         ++++++++++++

    |----|----|----|----|----|----|----|----|----|----|

   0.00     20.00     40.00     60.00     80.00    100.00

 

Universe of Discourse: From 0.00 to 100.00

 
The very hedge would modify that 3 point triangle shape and make it 7 points:
> (get-fs (create-fuzzy-value TEMP (tri 25 50 75)))
((25.0000 0.0000) (50.0000 1.0000) (75.0000 0.0000) )
> (get-fs (create-fuzzy-value TEMP very (tri 25 50 75)))
((25.0000 0.0000) (33.3333 0.1111) (41.6667 0.4444) (50.0000 1.0000) (58.3333 0.4444) (66.6667 0.1111) (75.0000 0.0000) )
 
Littler optimizations
 
We will finish off this article with some comments about some small optimizations that may be useful to you.  These optimizations can be summarized as "Use the faster fuzzy operations for your expert system if they don't invalidate your results."  Fuzzy set operations are relatively expensive.  However, there are some operations that are more expensive than others.  Care must be taken with modifying these values as they can significantly change the behavior of your expert systems.
 
Fuzzy correlation controls how the truth level (where 0 is completely FALSE and 1 is completely TRUE) of a rule's premise (IF portion) modifies the truth of the rule's consequents, whether fuzzy sets are truncated at the truth level (creating a plateau) or multiplied by the truth level (preserving the shape of the fuzzy set but shrinking it).  The inference engine provides two fuzzy correlation methods (minimum and product).  The minimum operation builds a fuzzy set that is the minimum of two fuzzy sets over the entire universe of discourse.  This is obviously cheaper (comparison operation) than the product fuzzy correlation method, which multiples the points of the two fuzzy sets to build the new fuzzy correlation set.
 
Fuzzy Inference controls how assertions are combined with facts already on the fact list.  Fuzzy inference has to do with asserting a fact in a fuzzy rule's right hand side.  This asserted fact is first modified by the fuzzy correlation method.  Then, fuzzy inference controls how the asserted fact is combined with a fact already on the fact list.  Unlike normal inference where new facts may be asserted, fuzzy inference combines the fact already on the fact list with the new fact.  This method type specifies how two fuzzy sets are combined:
MinMax - Takes the maximum of two fuzzy sets
Additive - Adds the two fuzzy sets together
Mean - Takes the average of the two fuzzy sets
Product - Multiplies the two fuzzy sets together
BoundedSum - Adds the two fuzzy sets together, cutting off any values over 1.0
 
Again, some of these types of fuzzy inference are faster than others (MinMax, Additive, and Bounded Sum are the fastest).
 
Finally, defuzzification deals with the method of selecting or computing one scalar value that best represents a fuzzy shape.  Obviously, it is hard to set a faucet to slow or a car to fast. We need a specific value that hopefully best represents the fuzzy set in its domain. This is a process called defuzzification.  The IECS supplies two functions for defuzzifying a fuzzy set: maximum-defuzzify and moment-defuzzify function.  The maximum-defuzzify function returns a defuzzified floating point value, which represents the defuzzified fuzzy set using the mean of maxima function.  It takes the average X value of the maximum points in the fuzzy set.  This method is faster than the moment-defuzzify function, but ignores any fuzzy operations that do not change the maximum value in the fuzzy set.  The moment-defuzzify returns a defuzzified floating point value, which represents the defuzzified fuzzy set using the centre of gravity (or first moment of inertia) function.  The centroid method is a good method to use in process control and robotics since it tends to smooth out the fuzzy region.  However, it is more expensive than maximum-defuzzify.

Tha' tha' tha' that's all folks!
 
Ok, that's it.  Hopefully, this article gives you some ideas for optimizing your fuzzy expert systems.  Unfortunately, these were guidelines, not golden rules.  A lot of experimentation and elbow grease are necessary to see if these methods work for you in your expert systems.  Good luck!
 
 
News: Object Inspector Component Suite (OICS) is now available!
 
We did it!  Thanks to a lot of hard work and the efforts of our beta testers, the Object Inspector Component Suite has just been released.  It is a remarkably solid and full featured object inspector for Delphi 6 and 7.  It is even better than when we talked about it in the last newsletter.  There are some awesome features that truly make it stand out from any other object inspector component:
 
- 100% Source Code 
- Includes Object Inspector Component and TRSItemListEditor Component (a Hierarchical TValueListEditor-like component for displaying TStrings, where each name=value item is a row in the object inspector and where the name may be a path, e.g., "Font.Name=Courier")
- Inspect One Object or Multiple Objects at Once (Like Delphi) at design-time or run-time
- Inspect Multiple Objects' Property Values in One Column or One Column per Object
- Comes with property editors for enumerations, sets, masks, regular expression masks, fonts, collections, TStrings, Dates and Time, TPicture, etc
- Modify property editors (called Property Presets) at design-time and run-time (see Figure)
- Use an Inplace Collection Editor (Items are embedded in the object inspector like regular TPersistent properties, please see the screenshot at top of page) and Regular Collection Editor 
- Control each property individually for visibility, read-only, font, hint, name alias, and more
- Add "Calculated" properties (e.g., fake properties) at design-time or run-time 
- Sort properties alphabetically or by category.  Categories may be defined at any level of the object property hierarchy
- View Properties Vertically or Horizontally 
 
More information, screenshots, and an evaluation version may be found at http://www.riversoftavg.com/object_inspector.htm
 
The OICS sells for $45 US.  For a limited time, the OICS is 10% off its regular retail price.  However, our loyal IECS customers can get an additional 10% off to make the OICS a steal at $36!  To order the OICS, run, don't walk, to our Order page (http://www.riversoftavg.com/order.htm) :-)  IECS users will need to email support@RiverSoftAVG.com for a coupon code to get their 20% off.
 
 
Tip: Using the IECS with the OICS

 
The new Object Inspector Component Suite works "out of the box" with the Inference Engine Component Suite.  However, the IECS uses some special property editors that the OICS does not know about.  The properties for facts, fact templates, rule, etc are special purpose property editors.  Thankfully, adding the property editors/presets to the OICS is not that hard.  The following tip can be performed with either the registered or evaluation versions of the IECS and OICS. 
 
To use the OICS with IECS, create a new application and drop down both components, the TInferenceEngine component and the TRSObjectInspector component.  To make the object inspector inspect the TInferenceEngine component, set the TRSObjectInspector.Component property to InferenceEngine1.  You will immediately see the properties of the inference engine displayed. 
 
If you ran your sample application, you would see that although the object inspector displays properties like DefinedTypes, FactTemplates, etc., it does not know how to edit them.  For our example, we are going to make a property preset which will display the Defined Types dialog when the user clicks on the ellipsis button for the property.
 
First, open the Presets collection editor for the object inspector.  Click the Add button to add a preset.  When you click the Add button, the Presets collection editor displays a list of all the TRSPropertyPreset collection item descendants you can create.  For example, if you wanted to make a preset which is a variation of the TRSTPicturePropertyPreset, you could create that class and then edit it for your special case.  In our case, we just need the default property preset, so click the Add Item menu item.  Change the Name of the preset to something descriptive such as "DefinedTypes preset."
 
Now, we want to make a dialog type object inspector.  Change the EditStyle property for the preset to esEllipsis.  This will ensure an ellipsis button is displayed for any property that this preset matches.  Notice that when we change the EditStyle property, the Actions property, which defines the set (e.g., more than one action may be performed by a given preset) of actions that an individual preset performs, is set to [pftEditStyle]. 
 
Now, to define the code that executes when the ellipsis button is clicked, we need to define an event handler for the OnEditButtonClick event of the preset.  Double click the OnEditButtonClick event and enter the following code:
 

procedure TForm1.RSObjectInspector1Presets18EditButtonClick(

  Sender: TObject);

var

   DefTypes: TIEDefinedTypes;

   Dialog: TDefinedTypesDialog;

begin

     // Get the TIEDefinedTypes class

     DefTypes := (Sender as TRSItemProperty).GetObjectProperty as TIEDefinedTypes;

     // Create the DefinedTypes dialog

     Dialog := TDefinedTypesDialog.Create(Self);

     try

        // set the engine to the TIEDefinedTypes.Engine property as there may be

        // more than one inference engine on the form

        Dialog.Engine := DefTypes.Engine;

        // execute the dialog... The defined types dialog ensures that the DefinedTypes

        // property is updated if the user clicks ok

        Dialog.Execute;

     finally

        Dialog.Free;

     end;

end;

 
Ok, now we have finished the action portion of the preset.  The final thing we need to do is make sure the preset matches on the DefinedTypes property.  Add 'TIEDefinedTypes' to the TypeNames TStrings property of the preset.  Also, add tkClass to the TypeKinds property of the preset.  Finally, add mtPropertyType to the MatchTypes property for the preset.  Setting these three properties tells the preset to try and match every item that is a class property of TIEDefinedTypes.  If an inspected property does match the preset, the preset will copy over its EditStyle and OnEditButtonClick property to the item.  That's it, at this point your preset should look like this:

      item

        HiddenItemClass = 'TRSPropertyPreset'

        Actions = [pftEditStyle]

        MatchTypes = [mtPropertyType]

        TypeKinds = [tkUnknown, tkClass]

        TypeNames.Strings = (

          'TIEDefinedTypes')

        Font.Charset = DEFAULT_CHARSET

        Font.Color = clWindowText

        Font.Height = -13

        Font.Name = 'MS Sans Serif'

        Font.Style = []

        ValueFont.Charset = DEFAULT_CHARSET

        ValueFont.Color = clWindowText

        ValueFont.Height = -13

        ValueFont.Name = 'MS Sans Serif'

        ValueFont.Style = []

        Name = 'DefinedTypes Preset'

        ParentTypeKinds = [tkUnknown]

        EditStyle = esEllipsis

        OnEditButtonClick = RSObjectInspector1Presets18EditButtonClick

      end>

 
If you run your sample application now, you will see an ellipsis button beside the DefinedTypes property that you can click and edit the defined types to your heart's content.  You can make presets for the other properties of the TInferenceEngine component in the same way.  Sometime in the future, we will release free source files to do this for you.  But in the meantime, this little tip gets you up to speed immediately and as a bonus gives a mini-tutorial on creating property presets in the OICS.
 
 
Download: HelpScribble Apprentice Updated
 
HelpScribble Apprentice, our freeware utility application for HelpScribble users, has again been updated version 0.9.9.2.  HelpScribble Apprentice has turned into a quite mature adjunct to HelpScribble with this release.  At this point, we use HelpScribble Apprentice almost exclusively, except for when we need to create the actual help file with HelpScribble itself.  HelpScribble Apprentice provides some features we would dearly love to see in HelpScribble, including:

- Unique Topic Editor abilities (edit multiple topics at once, sort lines of text, Object Inspector-like view of help topic footnotes)
- Unique Table of Contents Editor abilities (edit multiple topics at once, delete parent topics AND their children with one operation)
- Copy and Paste groups of topics, preserving the links between them

- Enhanced Link Dialog which adds new links including links to Delphi Objects, Methods, Properties, Events and Types

- Syntax Formatting Macros for Delphi Pascal, DFM Files, VB, VBScript, SQL, XML, and JScript
- Sort Topic Text Wizard (Automatically sorts lines in selected topics after certain keywords... very useful for sorting the "See Also" topics that HelpScribble creates for pascal files)
- Class Hierarchy Wizard (Automatically adds hierarchy topic to selected Delphi Class/Interface topics)

HelpScribble Apprentice is provided as a free utility. No warranties or guarantees are implied. Use at your own risk. REQUIRES HelpScribble for generating help files.  HelpScribble Apprentice may be downloaded from the www.RiverSoftAVG.com web site.
 
 
Download: Object Inspector Component Suite Demo Version
 
The newly released Object Inspector Component Suite is available in an demo version for all those "try before you buy" people out there.  The demo version is limited to display only one level deep for inspected objects, e.g., Font would be displayed but not Font.Style and is for evaluation only.  Please go to the http://www.riversoftavg.com/object_inspector.htm page and look for the download link.
Send mail to webmasterNO@SPAMRiverSoftAVG.com with questions or comments about this web site.
Copyright © 2002-2010 RiverSoftAVG
Last modified: September 20, 2010