Syntax Edit - Multiple syntax controls, different color schemes?

Print Page | Close Window

Multiple syntax controls, different color schemes?

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Syntax Edit
Forum Description: Topics Related to Codejock Syntax Edit
URL: http://forum.codejock.com/forum_posts.asp?TID=15026
Printed Date: 30 January 2025 at 9:36pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com

Topic: Multiple syntax controls, different color schemes?

Posted By: robin_l
Subject: Multiple syntax controls, different color schemes?
Date Posted: 22 August 2009 at 8:09am

I need to have more than one syntax editor control on a form, with independent syntax coloring. I assumed that the SetSyntaxAndColorScheme call would allow me to do this for each on an individual basis, but it looks as if the syntax controls store the coloring logic globally. This means that whatever was the last call to SetSyntaxAndColorScheme affects all syntax editor controls.

Is this what is supposed to happen? It makes the control rather restrictive if that is the case.

-------------
Product: Xtreme ToolkitPro 2009 (13.4.1)
Platform: Windows 7 Ultimate(64bit)
Language: Visual Studio 2010 (C++)

Replies:

Posted By: mdoubson
Date Posted: 22 August 2009 at 11:06am

You right - there is default mechanism of scheme sync for same app - see 2 running instances - they have different schemes in top and bottom but top synchronized with bottom but each app use independant scheme (the order of scheme used reversed in second app case). Need to look in the code more deep to find how to disconnect this sync - sure it is possible - there is no global scheme - what you see is 1st control reaction on notification about scheme changed from 2nd control. Make a flag to use or not such notification and you will have desired result. I can add it to Core finally and expose to ActiveX case also if people like to have such "Desync Mode" feature

-------------
Mark Doubson, Ph.D.

Posted By: robin_l
Date Posted: 23 August 2009 at 7:04pm

I think it is the LexConfigurationManager which is using the static s_ptrLexConfigurationManager_Default. This gets updated any time you alter the scheme in any CXTPSyntaxCtrl. What we need is to have each CXTPSyntaxEditCtrl keep their own CXTPSyntaxEditConfigurationManager rather than have a global one.

I seem to have some success with the following for each different CXTPSyntaxEditCtrl:

CXTPSyntaxEditConfigurationManagerPtr myManagerPtr = new CXTPSyntaxEditConfigurationManager();

mySyntaxEditCtrl.GetEditBuffer()->SetLexConfigurationManager(myManagerPtr);

Does this look right?

-------------
Product: Xtreme ToolkitPro 2009 (13.4.1)
Platform: Windows 7 Ultimate(64bit)
Language: Visual Studio 2010 (C++)

Posted By: mdoubson
Date Posted: 23 August 2009 at 11:12pm

Good idea but under special flag with default FALSE to keep existing mechanism because SYNC between different controls after scheme changed is a GOOD feature while your PROPOSAL to have different scheme for same type of source looks exotic - e.g. VS is not going this way...

This is very simple to make special build with non static version but not so simple to make switchable version where user can change mode after control created and all internal objects also constructed.

May be for your task just make specail build (use COMPILATION-TIME flag __UNIQUE_SCHEMES_BUILD__ to switch between cases):

in XTPSyntaxEditBufferManager.h:

#ifndef __UNIQUE_SCHEMES_BUILD__

static CXTPSyntaxEditConfigurationManagerPtr s_ptrLexConfigurationManager_Default; // The common default Configuration Manager instance.

static LONG s_dwLexConfigurationManager_DefaultRefs; // The reference count for common default Configuration Manager instance.

#else

CXTPSyntaxEditConfigurationManagerPtr s_ptrLexConfigurationManager_Default; // The specifi default Configuration Manager instance.

LONG s_dwLexConfigurationManager_DefaultRefs;

#endif

in XTPSyntaxEditBufferManager.cpp:

#ifndef __UNIQUE_SCHEMES_BUILD__

CXTPSyntaxEditConfigurationManagerPtr CXTPSyntaxEditBufferManager::s_ptrLexConfigurationManager_Default;

LONG CXTPSyntaxEditBufferManager::s_dwLexConfigurationManager_DefaultRefs = 0;

#endif

See results in VB used ActiveX build with given modifications:

I don't see the reason to change Core code (at least now)

-------------
Mark Doubson, Ph.D.

Posted By: robin_l
Date Posted: 24 August 2009 at 4:17pm

Hi Mark. Thanks, but I strongly prefer controls to be encapsulated. For example, if I set the font for a particular static text control I don't want the font for all static text controls in my application to change. Similarly, I would prefer to have syntax edit controls that are individually configurable and whose state does not depend on how a control elsewhere has been modified.

However, I think that the existing code allows for this without any special build, just by maintaing a separate CXTPSyntaxEditConfiguration member as I've indicated above--presumably this is why this mechanism has been included anyway. This seems preferable to building a private version of the CodeJock library. Testing what I have done at the moment (I currently am using 4 slightly differently configured syntax editor controls in an application) that mechanism seems to be working fine so far (no crashes or memory leaks yet

All I needed to do was derive a new class something like as follows:



class CSyntaxCtrlUnique : public CXTPSyntaxEditCtrl

{
CSyntaxCtrlUnique();
protected:

CXTPSyntaxEditConfigurationManagerPtr m_myManagerPtr;
};
 

CSyntaxCtrlUnique::CSyntaxCtrlUnique() : CXTPSyntaxEditCtrl()
{
m_myManagerPtr = new CXTPSyntaxEditConfigurationManager();

GetEditBuffer()->SetLexConfigurationManager(m_myManagerPtr);
}

Unless there is something non-obvious with this implementation that will come back to bite me, I'm happy to stick with this.

-------------
Product: Xtreme ToolkitPro 2009 (13.4.1)
Platform: Windows 7 Ultimate(64bit)
Language: Visual Studio 2010 (C++)

Posted By: mdoubson
Date Posted: 24 August 2009 at 5:13pm

Because this is not switchable solution - you can't change existed and loaded control to be unique scheme or common scheme and back.

If so - does not matter - derived class or compile-time flag - same fixed approach. For practival reason - your way is better as both variants exist in same dll or exe. I just expected from you analyze code more deep and propose dynamic switch mode for same existed and loaded control - e.g. I think about function like LoadSchemes(CString syntaxScheme, CString colorScheme, BOOL bUnique). This is possible.

-------------
Mark Doubson, Ph.D.

Posted By: nsharp
Date Posted: 06 November 2009 at 12:24pm

I just wanted to second this. We have a program that uses the syntax edit as pop-up sub-windows to edit macros and scripts within our program. Each instance will have a different set of variable names that we want highlighted, so each needs its own space. We could solve it by creating bogus file extensions, but that seems like a kludge. The fix robin_l mentions does indeed work for us, though it has the side-effect of making launching the syntax editors slower because the code ends up loading the scripts twice (then not using any of the loaded scripts once we introduce our dynamic runtime one).

Posted By: mdoubson
Date Posted: 06 November 2009 at 6:14pm

Color scheme is about 1 KB only

-------------
Mark Doubson, Ph.D.