SQL Syntax coloring-project download ...PING Firetox

Hi,
as promised the download link .
[www.file-upload.net]

The project is written in WD11.

99 percent of the code are part of an internal window named WI_Scintilla. The advantage is that you simply drag this internal Window on a form, set adequate anchoring and that's it.

Please see also the local procedures belonging to WI_Scintilla.
- a few thousand constants are part of scilexer.wl and scintilla.wl

well there is more to do. but in my opinion we allready have enough to play, test and, of course, to decide whether it makes sense to use this project as part of SQLManagerX Datacenter.

Let me know what you think, (french is okay)
nanali (at) wanadoo (dot) fr
Kind regards,
Björn Lietz-Spendig

Good Job Björn,

I've been working on something that needed a wlanguage editor at runtime. This should work perfectly.

Cheers!
Ken

Hello Bjöm

i have a made a class (because it's more simple for update and include in news project)
in windev 12 and you have to complete the begin for your name, your email etc .....

i have add some function like AddText , GetText, cut , copy,paste, etc ... (because for testing on data center i need to execute de query in the scintilla object).

and do too the load file with keyword for SQL (2 file in txt are in the zip file)

www.SQLManagerX.com/SQLManagerX/SQLEditor.zip

import the class in your project (and the file with constante that the class load)
then you have only one line for declaring :

init of project for exemple (or windows) :
objetScintilla est un C_SQLEditor("IMG_ObjetSintilla")

you need (instead of internal windows) an image field in you windows for receive the object scintilla. you can put a contextual menu in this like the internal windows
in example i create a image named : IMG_ObjetSintilla. an the constructor of the class need the name of field to charge object

it's work fine. in the data center it's very cool and easy to use.

Hello

the version of the data center 12.0.1.8 is on line
in this version i use the component of bjöm in the version with the class (c_SQLeditor)

you can download the version on the site
www.SQLManagerX.com in the download section

best regards
Firetox

Hi Björn,

You could use your wdinspire blog to post interesting stuff like that! It could serve as a repository where to download your work later. Ah! you could also send that to the solutions section of this forum once it's completed as you like.

I saw in LST 75 a full WD solution for syntax highlighting, but is a bit broken in some cases, with cursor flashing, etc.

I tested your project. (WD 14)

- WD complains that in procedure IW_Scintilla.OnCommand() the structure declaration of _NMHDR and _SCNotification hides the same structure declaration from the declaration section of the same file. - I deleted the declarations
- It informs me that IW_Scintilla.OnCommand() is not returning a value in all possible cases. Anyway.

Question: why the "EXTERN" must be inserted in the project ini code and not simply in the internal window? (Because it's an internal window, it can stay there. But that's ok it avoids duplication of declaration!)

Ok, after testing and comparing both solution: your implementation of scintilla is simply the best solution! Runs smooth, no problems, etc. And since scintilla has a very broad license even for commercial solutions, it's good.

What about models?

Since in WD14 it's just more advantageous in many cases to use model fields. So I created a field model out of your work. (It took me less than 5 minutes if you remove the 10 minutes search to get the WM_DESTROY event and test it. Yep, loosing time on small details...)

It works just great! Create a model, drop all the same exact code, copy all the functions and set them private manually. Then simply add an event with the others in the initialization part:

gnDestroy =  Event("OnDestroy", MySelf..Name, WM_DESTROY)

And in the OnDestroy event put the code that was in the OnClose of the internal window, adding a line to stop receiving event about the OnDestroy event itself.

I made a test windows with two MCDL_Scintilla fields in it and it was worked just ok with my first tests. I also got two "OnDestroy" events for both of them. Well... my two cents.

(Edit 1) - PS: I did put the EXTERNAL declarations in the model... and everything works fine. The compiler is not complaining either. So this is a 100% drop-and-play solution. You could do the same with the internal window.

Keep up the good work!

Best regards.



Edited 1 time(s). Last edit at 02/16/2009 05:25PM by Alexandre Leclerc.

Hi, Alexandre,

many thanks for the feedback. As allways, you made good points. Thanks!
YES, some structures are declared 2 times 'cause of a WINDEV 11 bug.

atm, I am having troubles with this forum, But I promise to discuss your feedback asap. Let's hope that I am able to upload this message. Bjoern

Hi Alexandre,
what about Models....

In case that "model fields" are what is called "Modèle de champs" in Windev FR then I am glad that we share the same idea.
--
Meanwhile I am convinced that implementing the Scintilla wrapper as class is a preferable solution. I want support for XML, SQL/PLSQL, C, D and W-Language.
So the idea is to create a core Scintilla class ->cScintilla and and to subclass it to whatever language you would like to support. It is not nessesary to use a class until you need support for a language which is not supported by Scintilla-like W-Language.

So here we have a first class OOP candidate.

Writing a wrapper around scintilla is almost a straightforward task.
Given .(from the scintilla programmers manual)
SCI_STARTSTYLING(int pos, int mask)

our wrapper will look similar to .

PROCEDURE StartStyling(pos is int, mask is int)
   SendMessage(gnHwndScintilla,SCI_STARTSTYLING, pos, mask)

A piece of cake. We just have to take care about string parameters and SendMessage()
Sometimes you need
s is string ASCIIZ on n
sometimes you need
s is Buffer

The only remarkable thing however is that we have to wrap about 200+ Functions.

Well this is just the naked wrapper. For a production quality implementation a litlle more work is required..
Brace matching, Search and replace, Setting Markers, Macro recording...

Regarding Search and Replace... I am also working on a binding to a PERL like regular expression engine. WINDEV's buildin regex is too weak)

Brace Matching -> find correspondending "(" for ")" , find correspondending "END" for "WHILE" or vice versa.
This is nessesary in order to implement code folding.
// Already done, but the code is a mess .(
--
I just had a conversation with my dutch collegue Frans and we agreed that it is time to setup an SCM in order to be more productive in our developer collaboration. This SCM, HF/CS based will be available via VPN.
Maybe we (you?, firetox?, ken?and me) can use this SCM to do some work together on this project.. we shoiuld use WD12 for a while.

??

LST 75
I bet this implementation uses RTF. Big mistake!

OkeeDokee, I have to look at the class Firetox (Frederic) has made.. Hope I found some time somewhere tomorrow.
Bjoern

Hi Björn,

Yep, I was talking about Modèle de champ . Since I do not have the English version I always have to guess. I don't know if I could download the English version and make it work.

Yes, I have some interest in contributing to the implementation of Scintilla in WD because I will most probably need it in a project in the coming year or the next one.

I also thing building a warper class is a very good Idea. I thought at:
- Bare-bone warper class around Scintilla
- Upper level class to ease the life of the programmers that want to use Scintilla without having to code all the talking with the warper.
- Plugin classes for the actual filter to use. (Words, logic, etc.)
- Maybe a plugin for the actual coloration? (So that a comment is always that way, and a keyword that way... and thus it's possible to change the "theme" whatever the actual language is being colored.)

Any-way, I'll give help as I can whatever you guys choose to structure the whole thing. I still have WD12 installed so there will be no problems. (Except for putting :: and : instead of . - I must say it took me a second to get used to that much more standard and simple syntax.)

Indeed, in LST 75 it was implemented using a RTF field.

Best regards.

Hi Alexandre,

- Bare-bone warper class around Scintilla
Sure.

- Upper level class to ease the life of the programmers that want to use Scintilla without having to code all the talking with the warper.
I hope we can support average joe code with a VERY SIMPLE INTERFACE. GUI

- Plugin classes for the actual filter to use. (Words, logic, etc.)
Thinking about implementing this with the factory pattern..

- Maybe a plugin for the actual coloration? (So that a comment is always that way, and a keyword that way... and thus it's possible to change the "theme" whatever the actual language is being colored.)

Enable themeing is not difficult.
Guess finally we will have a scintilla component. Plug it in and that's it.

atm I am thinking about how to ease and make event-handling more flexible,
Best idea so far - implementing the observer pattern.
( I prefer the name Publisher-Subscriber)
This will give us Java listerner look and feel.

cScintilla is class ; inherits sPublisher
---- Untested code

// Implementation of the Publisher Subscriber pattern (also known as Observer pattern)
// by Bjoern Lietz-Spendig

// Abstract Base-class
cPublisher is class

	PRIVATE
		// use dynamic array (list) implementation for collection of subscribers	
		Subscribers is array dynamic				
END
PROCEDURE Constructor()
	ubscribers = new array dynamic of 0 object dynamic
PROCEDURE Destructor()
	delete ubscribers
PROCEDURE RegisterSubscriber( oSubscriber is object dynamic )

	// if list does not contain this subscriber, add
	FOR i = 1 TO Dimension( ubscribers )
		IF ubscribers = oSubscriber THEN RETURN 
	END

	ArrayAdd( ubscribers, oSubscriber )
PROCEDURE UnregisterSubscriber(oSubscriber is object dynamic)

	// if observer is in the list, remove
	FOR i = 1 TO Dimension( ubscribers )
		
		IF ubscribers = oSubscriber THEN
			ArrayDelete( ubscribers, i)
			BREAK 
		END
		
	END
PROCEDURE NotifySubscriber( _message )
         // call update method for every subscriber. Note, here we use the push model
	ob is object dynamic  
	FOR EACH ELEMENT ob OF ubscribers
		 ob:Update( _message )
	END

The subscriber implementation is pretty simple

// Abstract Base-class
cSubscriber is class	
END
PROCEDURE VIRTUELLE Update( _message )

I hope you as OOP fan could accept this stuff ?, KInd regards, Björn

Hi Björn,

The OOP approach looks good to me.It becomes easier to use and maintain after.

As for the actual construction, it is not as clear in my mind as it is probably in yours. So if a Publisher/Suscriber patern is required, that's ok for me.

But I did not see it was needed (as I just said, I might not get the whole picture). So for me a simple warper which is used by some higher level classes is all what's required. Especially since the object instance must change if there are many in the same form / project at once - so that messages don't get mixed up.

But, if we do not want to duplicate a whole warper class for every single class instantiated, doing a global warper class with a subscription model - where the subscriber is the actual instance id of the control - looks good to me. (I might not understand your approach - sorry.) So this makes sure the messages are forwarded to the good object. - And if that is the goal, that would be an excellent opportunity to implement the singleton pattern so that all classes can create the subscriber class and register to it, knowing that only one instance is always used. That way the class becomes environment-independent and the developer that will use the class will not have to "do this and that" before using our nice implementation. Just import the class, then declare the syntax highlighter you want in whatever window-container and your in business - no code to change.

A simple final use case would be (cScintilla being the warper class used by cSyntaxHighlighter):

MySQLHighlighter is a cSyntaxHighlighter ("sql",MySelf)  // first argument, the filter to use, second the container for the final object - for a supported filter

MyCustomHighlighter is a cSyntaxHighlighter // for a custom filter
MyCustomHighlighter::AddWords("bla bla bla")
MyCustomHighlighter::Theme(blabla)

Or another approach:

MyHighlighterPattern is a cSyntaxPatternSQL // do it yourself - inherit from cSyntaxBasePattern
MyHighlighterTheme is a cSyntaxThemeDefault // do it yourself - inherit from cSyntaxBaseTheme
MyHighlighter is a cSyntaxHighlighter (MyHighlighterPattern, MyHighlighterTheme)

Ok, enought bla bla. As I said, I'm not getting the whole picture, I'm quite sure. But I'll go the way you want to structure the thing. Keeping it simple wherever possible and loaded with "plug-and-play"ness when it's time to use it are almost must-have objectives. - But I think you have the same objectives, as you mentionned it yourself.

Best regards.