From: Vincent Snijders
+
+ From: Marc Weustink

+ > You get this when you try to load a not existing font and
+ > the assume it is loaded and try to copy it (all with API
+ funcs). This is what mwEdit does very often.
+
+ Any ideas on how to solve or circumvent this problem?

We can change the API func that it doesnt load a font if not at least a fontname is available.

Marc

SHEdit (can be found in the FCL package), the editor used for 'the other FreePascal GUI IDE' Kassandra, has a GTK demo application with highlighting, and this runs very fast under Linux.

So is there any way to find out how they handled the fonts and worked around the drawing problem or is the real problem something else ? According to the description of the creating of a font everytime the style changes I could imagine a very slow process.
The highlighter: I have not seen the source of the current one but I am wondering if all methods are declared as virtual instead of dynamic ... I know that not all methods in the original were such. Is there a way to declare virtual methods at all in Freepascal ? Remember that virtual methods are optimized for speed as compared to dynamic methods for codesize. If the font is not the problem then something else has to be. I am unsure about the following but if I am not mistaken then part of the reason Windows has always been slow is the pre-loading of fonts during Windows startup. Hence the more fonts the slower it is. This was the reason I asked about how fast windows is when running Lazarus. Is anybody out there that is using it under Windows at this stage ?
I am also wondering if the stream access (is there such a thing ?) in Lazarus is optimized enough for us to be reading from it fast. Hence the original Parser uses Streams.

Regards, Alex

Delphi implements some kind of "resource caching" in the VCL in order to improve performance and use less resources under Windows. Sounds like the fonts should be dealt with in this "cached" manner. ie. when
they're first used they are cached for any further use. Maybe I'm oversimplifying the problem, but it's just a thought...

Cheers,
Kevin.

__________________________________________________ Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com

Currently I am busy and unable to work on Lazarus, but fear not. I will continue work ASAP. I am currently writing a bunch of HL7 interfaces and am unable to find the time for anything else.

Again, I would like our first improvement to be the speed issue. Find a way to avoid creating a new font each time the color/bold/style of the font changes and we will be in business. That should speed it up. For GTK, perhaps when they select a font, we try to load a normal, bold, italicized font right away and store them until the font is destroyed. Now, if it switches to BOLD, we have to free our current gtk font and load a new one.

Shane

>> 02/11/00 07:28AM >>>

Don't forget this control should save the contents in a real TStringList during a DestroyHandle, and repopulate the underlying control from this during the CreateHandle. When updating the items property, if HandleAllocated returns false you do the same operations on the temporary TStringList instead.

One the handle is allocated and populated from the TStringList the StringList can be free'd.

Sam

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

From: Marc Weustink

Any ideas on how to solve or circumvent this problem?

Are there Applications on Linux that currently have highlighting capabilities ? If so is there a visible impact on speed ? If there is none I am sure there is a way to preload/cache the required font and use it.

SHEdit (can be found in the FCL package), the editor used for 'the other FreePascal GUI IDE' Kassandra, has a GTK demo application with highlighting, and this runs very fast under Linux.

- Sebastian

+ From: Nico Aragon

+ >For now I'll go for the font and I'm thinking of a way to
+ >add a kind of a fontcache into the CreateFont API +
+ My unit isn't very featureful, but it "worked" and was reasonably
+ tested (I tested it to find out why it hadn't any effect :-D). It
+ was intended to be used by the programmer, but I don't think it
+ would be difficult to fit into the CL.
+
+ If you want it, please tell me whom to send it to. It would be
+ unpractical to install a CVS client just for this.

You can send it to me ()

Marc

Dave,

If you are on trying to compile lazarus for win32, try to edit mwcustomedit.pas so that it doesn't reference the windows units, but the LCLLinux (even if you are on win32).

I made replaced line 102-106 by
LCLLinux,
line 1151-1155 by

    if LCLLinux.HideCaret(Handle) then fCaretVisible := True;

and line 2774-2778 by

   if LCLLinux.ShowCaret(Handle) then fCaretVisible := True;

The reason you get these error messages is that lcllinux is supposed to have the same interface as the windows unit, but has some minor differences (e.g. passing pointer instead of var paramater). The LCLLinux unit calls into the windows unit when compiled on win32.

I haven't tried it under windows.
Shane

>> 02/16/00 02:37PM >>>

Are there Applications on Linux that currently have highlighting capabilities ? If so is there a visible impact on speed ? If there is none I am sure there is a way to preload/cache the required font and use it. As to a previous question I had : Does Lazarus under Windows display the same problem with the highlighting in mwCustomEdit ?

Alex

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

+ From: Vincent Snijders
+
+ > As to a previous question I had : Does Lazarus under
+ > Windows display the same problem with the highlighting
+ > in mwCustomEdit ?

What highlight problems. Under Linux it seems to have a problem with getting(or drawing) focus. (Everything is draw grey)

+
+ I tried to run lazarus under Windows but when I opened the + testform an illegal font was loaded and the program ended
+ with an access violation:
+ from the console output:
+ Gdk-WARNING **: gdk_font_load: font name
+ -*--normal-r-*-*-0-*-*-*-*-*-*-* illegal
+ An unhandled exception occurred at 0x00423EC2 :
+ Access violation

Hmm... this seems to be an inconsistency between the win32 and the linux gdk. Under linux it reports that the requested font can't be loaded. You get this when you try to load a not existing font and the assume it is loaded and try to copy it (all with API funcs). This is what mwEdit does very often.

Marc

As to a previous question I had : Does Lazarus under Windows display the same problem with the highlighting in mwCustomEdit ?

I tried to run lazarus under Windows but when I opened the testform an illegal font was loaded and the program ended with an access violation: from the console output:
Gdk-WARNING **: gdk_font_load: font name -*--normal-r-*-*-0-*-*-*-*-*-*-* illega
l
An unhandled exception occurred at 0x00423EC2 :
Access violation

+ From: Alexander Mehlhorn (AHM)

+ So is there any way to find out how they handled the fonts
+ and worked around the drawing problem or is the real problem
+ something else ?

Nope, I just did a check yesterday and mwEdit does 2 nasty things:

1 - For every line of source they (re)create 4 (or 5) fonts.

2 - They render all lines alltough only say 22 lines can be drawn.

+ According to the description of the creating of a font everytime
+ the style changes I could imagine a very slow process.

It is !

+ The highlighter: I have not seen the source of the current
+ one but I am wondering if all methods are declared as virtual
+ instead of dynamic ...

I can't remember, I only know that I didn't get a warm feeling when I saw the code ;-)

+ If the font is not the problem then something else has to be.

For now I'll go for the font and I'm thinking of a way to add a kind of a fontcache into the CreateFont API

Marc

Curtis White wrote

Concerning the font and syntax highlighting problem, we should take a look at the Moonshine source and see how they do it.

One question: Are you all totally ignorant? The font problem is absolutely trivial, and as I pointed out several days ago there is already a fully working editor with syntax highlighting, without any speed or font problems, and written in Free Pascal - SHEdit, of course. It has a demo renderer implementation for GTK, and there is a renderer for KCL. I _really_ can't understand how you all manage to waste your time here.

- Sebastian

Hola,

I've been spying you for some time :-)
I really can't help you, sorry, I have no spare time last months. But...

Nope, I just did a check yesterday and mwEdit does 2 nasty things: 1 - For every line of source they (re)create 4 (or 5) fonts.

Since Delphi uses an internal font caching system, mwEdit "can" do this. I didn't knew about this cache three years ago so... I wrote an unit to do font caching :-)

If you want it, I can translate identifiers and comments (as of now they're in Spanish).

2 - They render all lines alltough only say 22 lines can be drawn.

This is another problem. I wrote a syntax highlighter time ago but it was read-only. When I thought of making it R/W, I realized this problem. The "smart" way is to spawn a different low priority thread to continue rendering after the visible portion. Anyway most changes could stop their effect at the end of a line, only multiline comments (if I remember it well) matter otherwise. The initial rendering does benefit from using the thread. Are you using some kind of threads library in Linux?

+ one but I am wondering if all methods are declared as virtual + instead of dynamic ...

IMHO it shouldn't be a big problem.

+ If the font is not the problem then something else has to be. For now I'll go for the font and I'm thinking of a way to add a kind of a fontcache into the CreateFont API

My unit isn't very featureful, but it "worked" and was reasonably tested (I tested it to find out why it hadn't any effect :-D). It was intended to be used by the programmer, but I don't think it would be difficult to fit into the CL.

If you want it, please tell me whom to send it to. It would be unpractical to install a CVS client just for this.

greetings

Nico

Concerning the font and syntax highlighting problem, we should take a look at the Moonshine source and see how they do it. They use plugins to define the syntax highlighting for different languages, including Pascal. It seems to do a nice job of drawing the fonts and highlighting. It might be worth a look to see how they are handling the fonts. If I can get a little time in the next couple days, I will try to take a

So is there any way to find out how they handled the fonts and worked around the drawing problem or is the real problem something else ?

As I wrote SHEdit I can tell you that there definitely is no problem with GTK regarding the speed...
The GTK demo for SHEdit creates 4 fonts on startup (normal, bold, italics, bold & italics) via gdk_load_font and stores the handles. The drawing is done with gdk_draw_text which takes the font handle as its second argument.

I cannot say anything on mwEdit and/or Lazarus, I only know that something must go very wrong there if the drawing speed is too low...

- Sebastian

Are there Applications on Linux that currently have highlighting capabilities ? If so is there a visible impact on speed ? If there is none I am sure there is a way to preload/cache the required font and use it. As to a previous question I had : Does Lazarus under Windows display the same problem with the highlighting in mwCustomEdit ?

Alex

Help!

I'm new to this, I can't compile the lazarus source, I get the following

mwcustomedit.pas(1827,58) Error: Incompatible type for arg no. 8: Got
VOID_POINTER, expected LONGINT
mwcustomedit.pas(1877,43) Error: Incompatible type for arg no. 8: Got
VOID_POINTER, expected LONGINT
mwcustomedit.pas(1904,58) Error: Incompatible type for arg no. 8: Got
VOID_POINTER, expected LONGINT
mwcustomedit.pas(1921,58) Error: Incompatible type for arg no. 8: Got
VOID_POINTER, expected LONGINT
mwcustomedit.pas(1967,43) Error: Incompatible type for arg no. 8: Got
VOID_POINTER, expected LONGINT
mwcustomedit.pas(1992,58) Error: Incompatible type for arg no. 8: Got
VOID_POINTER, expected LONGINT
mwcustomedit.pas(2054,48) Error: Incompatible type for arg no. 8: Got
VOID_POINTER, expected LONGINT
mwcustomedit.pas(2072,58) Error: Incompatible type for arg no. 8: Got
VOID_POINTER, expected LONGINT
mwcustomedit.pas(2206,69) Error: Incompatible type for arg no. 8: Got
VOID_POINTER, expected LONGINT
mwcustomedit.pas(2226,58) Error: Incompatible type for arg no. 8: Got
VOID_POINTER, expected LONGINT
mwcustomedit.pas(2247,58) Error: Incompatible type for arg no. 8: Got
VOID_POINTER, expected LONGINT
mwcustomedit.pas(2265,58) Error: Incompatible type for arg no. 8: Got
VOID_POINTER, expected LONGINT
mwcustomedit.pas(2289,58) Error: Incompatible type for arg no. 8: Got
VOID_POINTER, expected LONGINT
mwcustomedit.pas(2310,58) Error: Incompatible type for arg no. 8: Got
VOID_POINTER, expected LONGINT
mwcustomedit.pas(2343,58) Error: Incompatible type for arg no. 8: Got
VOID_POINTER, expected LONGINT
mwcustomedit.pas(2361,58) Error: Incompatible type for arg no. 8: Got
VOID_POINTER, expected LONGINT
mwcustomedit.pas(2821,36) Error: Incompatible type for arg no. 3: Got
SCROLLINFO, expected LPCSCROLLINFO
mwcustomedit.pas(2837,36) Error: Incompatible type for arg no. 3: Got
SCROLLINFO, expected LPCSCROLLINFO
mwcustomedit.pas(2901,26) Error: Incompatible type for arg no. 2: Got
TPOINT, expected POINT
mwcustomedit.pas(4159,34) Error: Incompatible types: got "POINT" expected
"TPOINT"
mwcustomedit.pas(4602,1) Fatal: Internal error 7453984
make.exe[1]: Leaving directory `c:/pp/source/lazarus/components/mwedit'

any advise?
Dave.

Does the SHEdit implement parsing of source that is non-pascal/delphi ?

You can add highlighters for whatever you want. At the moment, there are two highlighters: One for Pascal/Delphi/FPC, and one for XML and HTML sources.
A highlighter consists of two parts: You have to write the highlighting algorithm itself (a function which gets a pointer to the input line; the output is a 'tagged' string where a special character is used to switch the font styles and colors. Additionally you have a few status bits per line which you can use, e.g. for marking a line as being part of a multi-line comment). The other part is to define all the styles (font + color), but this is dependent of the SHEdit renderer implementation.

- Sebastian

Hi there,

Does the SHEdit implement parsing of source that is non-pascal/delphi ? Eg. At some later stage when Lazarus supports database connections (I know some of this is already possible) from its components and allows the construction of SQL Code it would be nice to have different highlighters for SQL or even enable the endusers to hook in their own parsers to enable the highlighting features (something that is missing straight from Delphi).

Regards, Alex

Marc Weustink wrote

Sure, but look at my story (It's mine so I cant talk for others). Once you have decided to use a certain editors and once you have it allmost working, you don't look to other editors that fast.

I didn't say that you should dump mwEdit and use SHEdit instead; I just wanted to point out that there is a working editor which does not have the problems you are currently having with mwEdit.

SHEdit itself is an abstract editor core, it is a FCL component. You implement the interface methods for drawing, keyboard, clipboard etc. in whatever class you want.

OK, there is a GTK renderer, but its platform dependent, we can't use it

This is only a demo renderer. If you wanted to adapt SHEdit to LCL, I would take the KCL version as template.

(only as a source for an independent version). As a first estimate I think you still end up doing the same things as we do now, with the only positive that we made the renderer ourselves and that it could be less resource consuming.

...and SHEdit works for about 8 months now ;)

- Sebastian

+ One question: Are you all totally ignorant? The font problem is
+ absolutely trivial, and as I pointed out several days ago there is
+ already a fully working editor with syntax highlighting, without any
+ speed or font problems, and written in Free Pascal - SHEdit,
+ of course.

Sure, but look at my story (It's mine so I cant talk for others). Once you have decided to use a certain editors and once you have it allmost working, you don't look to other editors that fast.

+ It has a demo renderer implementation for GTK, and there is a renderer
+ for KCL.

Thats a point, are we going to put effort in porting a non LCL component to a LCL component. How much work would that be, I don't know. OK, there is a GTK renderer, but its platform dependent, we can't use it (only as a source for an independent version). As a first estimate I think you still end up doing the same things as we do now, with the only positive that we made the renderer ourselves and that it could be less resource consuming.

+ I _really_ can't understand how you all manage to waste your
+ time here.

Call it a waste of time. I don't see it that way. With the introduction of mwedit a lot of things are changed/improved on Lazarus. All the efforts we've put in we had to do it sometime anyhow. Most of the excisting/new components can use the new code.

Marc

From: Sebastian Guenther

> OK, there is a GTK renderer, but its platform dependent, we can't use it This is only a demo renderer. If you wanted to adapt SHEdit to LCL, I would take the KCL version as template.

I have been thinking to make an LCLSHEdit class which uses the LCLLinux units to access platform and widget specific functions. I hav given an quick look at the gtkshedit example and I think it could be done (given enough spare time ;-) ).

That it could be done quiete easily IMHO is because so much effort has been done in making LCLLinux (which really should get a different name!) in order to get mwedit working.

Therefore I would like to give it a try this weekend and I just checked out kcl from the cvs.
(So put the lclshedit component on my name on the component status list ;-) ).

Hope to send you a working example prog sometime next week.

Vincent Snijders.

Hi there,

Another point to my previous e-mail. I did not mean to say use the mwHighlighters at this stage. What I mean to say is that the current highlighter structure of mwCustomEdit is not flexible enough for endusers of Lazarus to create their own highlighters and easely add new keywords. This means do NOT hardcode the use of a range of highlighters ! Rather create an interface for people to build their own highlighters and hook them in. (like the toolsapi) I can imagine the use of highlighting to be extremely important for more code than just simply Pascal. However for this to be possible we require a far better inheritance scheme for highlighters than the current one. I should have some code available for Delphi by the end of next week ( I require this for some other work of my own therefore Delphi). I am trying to create the following :
- base class that does the moving along the code stream
- inherited classes that are responsible for defining the identification tokens of the language
- dynamic creation of hashtables in runtime as compared to the current Func1..n structure for keywords
- keyword identification done by the base class altought the definition rests with the inherited class
- a standard tokentype as compared to new tokentypes for every language
- standardizes classes for all language parsers from which then descends the highlighter unlike
straight forward highlighter, parser and baseclass in one

90% of the above code is already done. This code will be released opensource as I have no intention of inlcuing it into the AHM Triton Tools. However the first person to receive this code will be Martin Waldenburg as still 10% of it is based on previous functions. After that I will send a message to this list so people can go and download the source should anyone be interested. Conversion to Lazarus should be seamless as there are no Windows Controls :)

As I have just received a reply on my previous e-mail : In Delphi we can install packages that allow us to interface to the internal toolsapi. Is this functionality available in Lazarus ?

Regards, Alex

Hello,

of SQL Code it would be nice to have different highlighters for SQL or even enable the endusers to hook in their own parsers to enable the highlighting features (something that is missing straight from Delphi).

Delphi 4+ has highlighters for C and SQL.

I'm not sure, but I think to have seen a description of the pluggable highlighters too.

greetings

Nico