Codejock Forums Homepage
Forum Home Forum Home > Codejock Products > Visual C++ MFC > Syntax Edit
  New Posts New Posts RSS Feed - Multiple syntax controls, different color schemes?
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

Multiple syntax controls, different color schemes?

 Post Reply Post Reply
Author
Message
robin_l View Drop Down
Senior Member
Senior Member


Joined: 15 October 2006
Status: Offline
Points: 117
Post Options Post Options   Thanks (0) Thanks(0)   Quote robin_l Quote  Post ReplyReply Direct Link To This Post Topic: Multiple syntax controls, different color schemes?
    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++)
Back to Top
mdoubson View Drop Down
Senior Member
Senior Member
Avatar

Joined: 17 November 2008
Status: Offline
Points: 1705
Post Options Post Options   Thanks (0) Thanks(0)   Quote mdoubson Quote  Post ReplyReply Direct Link To This Post 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

Back to Top
robin_l View Drop Down
Senior Member
Senior Member


Joined: 15 October 2006
Status: Offline
Points: 117
Post Options Post Options   Thanks (0) Thanks(0)   Quote robin_l Quote  Post ReplyReply Direct Link To This Post 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++)
Back to Top
mdoubson View Drop Down
Senior Member
Senior Member
Avatar

Joined: 17 November 2008
Status: Offline
Points: 1705
Post Options Post Options   Thanks (0) Thanks(0)   Quote mdoubson Quote  Post ReplyReply Direct Link To This Post 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)
Back to Top
robin_l View Drop Down
Senior Member
Senior Member


Joined: 15 October 2006
Status: Offline
Points: 117
Post Options Post Options   Thanks (0) Thanks(0)   Quote robin_l Quote  Post ReplyReply Direct Link To This Post 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++)
Back to Top
mdoubson View Drop Down
Senior Member
Senior Member
Avatar

Joined: 17 November 2008
Status: Offline
Points: 1705
Post Options Post Options   Thanks (0) Thanks(0)   Quote mdoubson Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
nsharp View Drop Down
Newbie
Newbie


Joined: 20 March 2008
Status: Offline
Points: 3
Post Options Post Options   Thanks (0) Thanks(0)   Quote nsharp Quote  Post ReplyReply Direct Link To This Post 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).

Back to Top
mdoubson View Drop Down
Senior Member
Senior Member
Avatar

Joined: 17 November 2008
Status: Offline
Points: 1705
Post Options Post Options   Thanks (0) Thanks(0)   Quote mdoubson Quote  Post ReplyReply Direct Link To This Post Posted: 06 November 2009 at 6:14pm
Color scheme is about 1 KB only
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 12.04
Copyright ©2001-2021 Web Wiz Ltd.

This page was generated in 0.156 seconds.