Default syntax highlight

It is easy - when you run syntax edit base app you should tell your app where to get schemes - usually this is a folder EditConfig in same place you put your app (exe). In this folder there are subfolders Schemas and Themes and also ini-file (by default - SyntaxEdit.ini). I copy this file as SyntaxEditVC.ini and clean it to have only one scheme:

[Schemes]
CPP=Schemas/_cpp.schclass  ; Visual C++

[Themes]
Default=Themes/colorSchema0.ini
Alternative=Themes/colorSchema1.ini

 

Find in your app the line (this is MFC version but VB looks similar)

Call SyntaxEdit.DataManager.FileExt = ".sql" in your initialization step

You need to understand last year syntaxedit modifications - e.g. this is modification to use non-ini and file-based configuration [sScheme and sColorTheme  - multi-lines strings with syntax and colors - see MDITextEditor sample code

GetEditCtrl().m_bUseMonitor = FALSE;

if (GetEditCtrl().GetEditBuffer())

GetEditCtrl().GetEditBuffer()->SetFileExt(_T(".cpp"));

GetEditCtrl().SetSyntaxAndColorScheme(sScheme, sColorTheme);

You can use any code to read your syntax and color scheme files into 2 strings and keep \r\n inside and use this 2 strings in

GetEditCtrl().SetSyntaxAndColorScheme(sScheme, sColorTheme); //my h-files to make compiled version [prebuid CPP case - like default]

I did the paragraph find/replace with Notepad++ instead of word and it saved all the typing, thank you 

Problems remain. This is the first block of file _sql_schclass.h:

CString sScheme, sColorTheme, sb;

/// SQL ///   
sb += _T("
lexClass:
    parent:file        = <*.sql>
    name            = c_SQL
    caseSensitive    = 0
    txt:colorFG    = 0x000000
    global:EditReparceTimeout_ms = 15000
    global:OnScreenSchcacheLifeTime_sec = 0
    global:ParserThreadIdleLifeTime_sec = 300
");

and at end of file:

sScheme = sb;
sb.Empty();

But of course produces the following errors on compile (for each block):

Error    1    error C2001: newline in constant

Since every line of text on a new line in the block either needs a '\' or remove all the line feeds.

I did solve this error:

Error    1    error C2143: syntax error : missing ';' before '+='

The config header file(s) cannot be included as "real header" files at the top of the cpp, but has to be embedded since it's code not class! Doh!

BOOL CQueryEditor::OnInitDialog()
{
    CXTPDialog::OnInitDialog();

    CRect rc;
    GetDlgItem(IDC_PLACEHOLDER)->GetWindowRect( &rc );
    ScreenToClient( &rc );

    BOOL bCreate = m_ctrlSynEdit.Create(this, TRUE, TRUE);
    m_ctrlSynEdit.ModifyStyleEx(0, WS_EX_CLIENTEDGE);   
    m_ctrlSynEdit.MoveWindow(&rc); //&rcEdit);   

    #include "_sql_schclass.h"
    #include "ColorsDataEntry.h"

...

Do you know what causes the huge lag when using the "file" based method? I'd really like to use it and it works perfectly except for the lag.

It's even more pronounced in Debug vs Release so maybe related to memory allocation/deallocation? I'm just guessing here but hope someone might have the answer.

Thank you!

uploads/20091130_152844__sql_schclass.zip

The ".h" file method doesn't seem to work either. I have attached _sql_schclass.h if anyone is interested.

The dialog opening speed is very good. Probably because it's not doing anything Maybe I've got something wrong in the header file. If so I'll be darned if I know what it is. I didn't seem to encounter any error messages.

I performed the following tests:

1. I copy/pasted some SQL into the edit box. No syntax highlighting.
2. I typed some SQL directly into the edit box. No syntax highlighting.

Code:

    m_ctrlSynEdit.SetConfigFile(_T(""), FALSE);
    m_ctrlSynEdit.m_bUseMonitor = FALSE;

    CXTPSyntaxEditBufferManager* pDataMan = m_ctrlSynEdit.GetEditBuffer();   
    ASSERT(pDataMan);
    if (pDataMan)
    {
        #include "_sql_schclass.h"
        #include "ColorsDataEntry.h"
        m_ctrlSynEdit.SetSyntaxAndColorScheme(sScheme, sColorTheme, FALSE, FALSE);
    }

Thank you mark, that did the trick with the ".h" file.

My ".h" file produced a number of errors and wouldn't highlight properly but it did "sort of" work. I prefer the external file schema since you don't have to recompile every time you change a setting. I guess I'll have to trace until I find where the lag is coming from.