That is a good start. Those 3 properties should get their own section
in the session props panel, and they should be disabled when a plugin
registers a custom tokenizer. Also, a red label above them in that
section should indicate that these properties cannot be configured
here, but they can be in the Global Preferences Sheet tab for that
session's plugin.
Rob
On Tue, Mar 10, 2009 at 5:22 PM, Gerd Wagner <ger...@t-...> wrote:
>
> I think I understand what you mean. Probably moving the tabs in "New Session
> Properies" to our Alias properties would come quite close to what you are
> saying. I see that this would be the most correct from a logical point of
> view. But I believe that users wouldn't appreciate this much of
> configuration. If that is true a compromise is needed and I suggest the
> following:
>
> If a custom query tokenizer exists we should disable editing of
> - statement separator
> - start of line comment
> - remove multi-line comments
> (or at least those of the three that are predefined by the custom tokenizer)
> set them as well as we can on base of the custom query tokenizer and tell
> the user that they were set by a plugin.
>
> That is a compromise but it makes things quite clear for users and is rather
> easy to implement. It clearly doesn't solve discrepancy between "New Session
> Properies" and custom tokenizers.
>
>
> Would that be OK?
>
>
> Gerd
>
|