A few questions

 

I'm not going to use the SyntaxEdit until this is implemented.

 

PS. Funny you mention those functions. I needed the exact same things some months ago. I sense you're developing my application ;)

 

syntaxEdit.EnableTokenizer(TRUE);

 

CMySyntaxEdit::OnColorize(params) {...}

Give me some feedback about the speed of current version.

Be also sure that YOU HAVE PROPER SYNTAX File - e.g. attach it to your post note so I can also try it  

Btw - window -> split is not for current test case (almost disable).

I am sorry about your questions - your asked another persons in the past. I see the use of CJ SyntaxEdit in the current architecture.

 

Yes you can do it. We have architecture to use only memory-located syntax and color schemes - so you can modify it on fly

Hi, we already have code in current version of SyntaxEdit for language definitions modification runtime by code.

 

Are you ready to participate in SyntaxEdit extention project? Write the spec you consider have potential and we can discuss it (foreign links as actiprosoftware is not enough!).

 

Even LineModificationMarking need to have all-cases-covered spec (e.g. delete line  - undelete line and so on)

 

With all due respect, the idea behind using commercial code libraries is that there should be sufficient documentation and examples to allow us to implement things WITHOUT having to pick through the raw source code. The SyntaxEdit control, after lots of initial adverse comments, now seems to me to be sufficiently stable and robust that I'd really like to use it. BUT... it is one of the most complex CodeJock components and having a single example file, plus rather terse and (by your own admission) incomplete documentation makes this more of a struggle than it should be.

 

For my purposes, I still feel that the reliance on an immutable external config file is too limiting and I echo the comments made earlier about the need to allow language definitions to be changed at runtime. I'd also prefer the option of NOT using a configuration file, but instead of passing the information direct (including the .schclass information as a resource would be my first choice--I don't like the idea of "magic" configuration files that users could alter).