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