        » faq   
|
|
Dynamic AutoComplete Tool FAQ
What about the DACT licensing terms; can the component be redistributed royalty-free?
I'm wondering about where the drop-down data gets stored
between sessions - Is this where the "StringSource" property comes in?
Would I be able to provide the autocomplete persistence for myself so I
can store this
info somewhere along with the other app settings?
I've just learned that Visual Studio .NET 2005 (formerly codenamed 'Whidbey') supports autocomplete. Why then, should I buy your component?
I want to redistribute the AutoComplete component with my application.
Which files do I need to include in my setup?
When installing my application, should I place the AutoComplete component into Global Assembly Cache (GAC)
or should I deploy it as a private assembly?
Is it possible to enable/disable autocomplete for individual controls at runtime?
I've got a Login form with a LoginName TextBox. How can I ensure that
the user-entered login name is saved into AutoComplete only when the login name is valid (i.e. the
logon process is successful)?
How can I customize the AutoComplete related properties within the VS.NET designer?
What are the inner workings of your component?
What about the DACT licensing terms; can the component be redistributed royalty-free?
Yes. One developer license entitles you to redistribute the runtime DACT assemblies to any number of
users with any number of applications you create. For details plese see the
DACT license agreement (RTF file, 16KB).
I'm wondering about where the drop-down data gets stored
between sessions - Is this where the "StringSource" property comes in?
Exactly! By default, DACT stores the user-entered strings in
registry under HKCU\Software\LaMarvin\AutoComplete\<Namespace> hive,
where <Namespace> is the value of the Namespace extender
property that is added by the component to controls on a form.
Would I be able to provide the autocomplete persistence for myself so I
can store this
info somewhere along with the other app settings?
If you want to do this, you'll have to implement the
IStringSource interface and associate the implementation with the
appropriate control at runtime. The CustomStringSource
sample (available in C# and VB.NET) illustates the concept. The sample
is installed under <DACT installation folder>\Samples\CustomStringSource .
I've just learned that Visual Studio .NET 2005 (formerly codenamed 'Whidbey') supports autocomplete. Why then, should I buy your component?
This is a very frequent question, indeed. I've put up a
dedicated page that hopefully answers that
question completely.
I want to redistribute the AutoComplete component with my application.
Which files do I need to include in my setup?
You'll need to redistribute the following files:
LaMarvin.Windows.Forms.AutoComplete.dll - this is the component's main assembly.
LaMarvin.Windows.Forms.AutoComplete.Interop.dll - this is the component's interop assembly.
Note: when you create your setups with the Visual Studio .NET Setup project, these files are included
in the setup automatically.
When installing my application, should I place the AutoComplete component into Global Assembly Cache (GAC)
or should I deploy it as a private assembly?
In general, I wouldn't recommend putting the component into the GAC. In general, I wouldn't recommend putting
any third-party component into GAC, because it effectively brings back the DLL hell issues of the COM era
back to .NET development. In special cases, however, it might be feasible.
For more information, check out Jeff Richter's great
series of articles
about .NET deployment issues (from the MSDN Magazine).
Is it possible to enable/disable autocomplete for individual controls at runtime?
Originally, Dynamic AutoComplete Tool has been designed as a "no coding necessary" component,
so no runtime customizations were meant to be supported.
Due to popular demand, we've added full runtime autocomplete customization support
starting with the 1.1 release.
Nevertheless, there is a workaround that allows one to control autocompletion at runtime even
with the older versions (1.0.0.39 and lower).
The workaround is documented and illustrated in a sample solution.
Here is the VB.NET version and
here is the C# version.
I've got a Login form with a LoginName TextBox. How can I ensure that
the user-entered login name is saved into AutoComplete only when the login name is valid (i.e. the
logon process is successful)?
First, you'll have to disable the auto-saving feature by setting the
FormManager.AutoSaveStrings property to False (you can do this either at design-time or at runtime).
The property is exposed on the FormManager class:
Me.FormManager1.AutoSaveStrings = False
Next, you'll need to call the UpdateStringSource(Me.LoginName) method after you've validated
the login name and password entered by the user:
If <user name and password valid> Then
Me.FormManager1.UpdateStringSource(Me.LoginName)
End If
This online demo illustrates a similar usage pattern
for a Search dialog - the search
string is saved only if something is found.
How can I customize the AutoComplete related properties within the VS.NET
designer?
Dynamic AutoComplete Tool extends all System.Windows.Forms.TextBox and
System.Windows.Forms.ComboBox controls (and their descendants) with four AutoComplete-related
properties. These properties are Enabled , Options , Namespace and StringSource .
You can modify these properties for individual controls in the VS.NET Property Window
(they're grouped under "AutoComplete" category).
Check out the online tutorials page for more information on design-time interaction.
What are the inner workings of your component? Do you use any undocumented
APIs / interfaces?
Dynamic AutoComplete Tool doesn't use any undocumented system calls. It is a lightweight, managed
wrapper around the Shell-provided AutoComplete COM APIs. Its unique
design time support and efficient runtime operation allow for easy, point-and-click
integration into any .NET Framework Windows Forms application. By purchasing Dynamic AutoComplete Tool, you'll also get
complete source code and .IDL files, so you can easily see how everything has been done.
|