Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2003-10

CVS Updates

30 messages · 8 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Andrew Johnson
Marc Weustink wrote 14 lines
At 02:27 4-10-2003, Andrew Johnson wrote: >On Fri, 2003-10-03 at 20:21, Marc Weustink wrote: >however there _is_ also the issue that because DoubleBuffering needs to >be done in the interface for GTK(I think), aka think GTK2, that it >probably means it somehow needs to be done within the win32 interface >itself. > >If this can be worked out for Win32 the issue is moot anyway. But that >will require quite a bit of thought and possibly reconsidering how >DoubleBuffering should be done overall. Hmm.. indeed. First, where do we want doublebuffering to be handled. Should it be part of the interface or should it be part of the LCL.

its a tricky question, because GTK2 automatically does doublebuffering, which means sometimes we have to manage it and do it ourselves. So on that note I would say defintely use or at least initiate it in the interface if at all possible.

When is it used ? Only while in the LM_PAINT message ?

well it should be whenever it can be. No matter how its done in VCL :D

In the VCL it is only handled in the paint message yes. In GTK2 its almost always used by default but because of the having to handle it ourselves for custom widgets then likely as far as its concerned it will also only be in the Paint message, however it is done from beginpaint/endpaint so anywhere that uses those functions will automatically get it in GTK2.

So I suppose one way would be to make each interface BeginPaint always return a DoubleBuffer DC, and EndPaint bitblt it to the real one, much like I am essentially doing for gtk2 by calling its own native begin and end paint methods. This would allow it to be done anywhere those functions are called, and since they should be being used by the LCL whenever a paint message doesn't pass its own DC that might allow us to do this. It would of course mean not actually using the native win32 BeginPaint/EndPaint(or not returning handling things the same way), and would require caching and keeping track of the extra info somehow, and thus in all the win32 functions have offset functions to move to relative position if a buffered dc(aka in the cache). Maybe this is too complicated though...

Andrew

Reply by email

Marc Weustink
Andrew Johnson wrote 19 lines
On Fri, 2003-10-03 at 20:21, Marc Weustink wrote: > You won't need this on win32, since it supports ExtTextOut natively :-) > So it draws the text *with* background already. > > Be aware that most win32 based interface calls don't need much translation. > Especially for synedit, since in it's origin it was pure win32 based. > > So don't try to mimic draw functs on win32 which are win32 native. Yeah I wondered. however there _is_ also the issue that because DoubleBuffering needs to be done in the interface for GTK(I think), aka think GTK2, that it probably means it somehow needs to be done within the win32 interface itself. If this can be worked out for Win32 the issue is moot anyway. But that will require quite a bit of thought and possibly reconsidering how DoubleBuffering should be done overall.

Hmm.. indeed. First, where do we want doublebuffering to be handled. Should it be part of the interface or should it be part of the LCL.

When is it used ? Only while in the LM_PAINT message ?

Marc

Reply by email

Andrew Johnson
Marc Weustink wrote 7 lines
You won't need this on win32, since it supports ExtTextOut natively :-) So it draws the text *with* background already. Be aware that most win32 based interface calls don't need much translation. Especially for synedit, since in it's origin it was pure win32 based. So don't try to mimic draw functs on win32 which are win32 native.

Yeah I wondered.

however there _is_ also the issue that because DoubleBuffering needs to be done in the interface for GTK(I think), aka think GTK2, that it probably means it somehow needs to be done within the win32 interface itself.

If this can be worked out for Win32 the issue is moot anyway. But that will require quite a bit of thought and possibly reconsidering how DoubleBuffering should be done overall.

Andrew

Reply by email

Andrew Johnson
Micha Nelissen wrote
Can you explain this a little more detailed? What is the cause of the flickering exactly? The win32 interface also has this problem.

I am not sure its quite the same issue though it might be.. basically SynEdit calls ExtTextOut on each block of text, for instance on a line with

Procedure MyFunction(someclass : TBlah);

would call ExtTextOut something like 8 times. Now since SynEdit supports using a different background colour for each block of text, then this means ExtTextOut will get called with ETO_OPAQUE.

This means that most of the time a block of text calls ExtTextOut, that block of text will get filled with the current brush before drawing the text. This means the text essentially disapears from the screen and then reapears. Since there are so many blocks this results in constant flashing all over the place every time something is invalidated. So in this case there are 8 potential flashes any time invalidate/repaint etc. What I have done in the GTK interface, is if ETO_OPAQUE is passed, I create a buffer pixmap of the size of the passed rectangle, and perform actual filling and drawing of text on that offset, then draw pixmap, meaning the block is drawn in one step to the screen.

I don't know how easily this could be done in win32 since you would have to create a buffer hdc and hbitmap, calculate relative offsets, based on whether it was buffering or not, then draw to it, which also means possibly a fair bit more amount of memory needed etc.

And I don't think CreateCompatibleDC copies pen brush and font info does it? So you might have to get that and assign it to both.

Assuming I have a clue the appened is an example of what _might_ work. I probably made mistakes, I am not sure of the offset etc. I just threw it together in this e-mail without any double checking or even reading msdn docs so it may not even compile.... But feel free to try (and fix) at your own risk :)

Andrew

Function TWin32Object.ExtTextOut(DC: HDC; X, Y: Integer; Options:
Longint; Rect: PRect; Str: PChar; Count: Longint; Dx: PInteger):
Boolean;
var
  Buffered : Boolean;
  Buffer : HDC;
  BufferBitmap : HBitmap;
  bX, bY, bWidth, bHeight : Longint
  BufferDrawRect : TRect;
  DrawRect : LPRect;
  OldBrsh, OldPen, OldFont : hObject;
Begin
  Assert(False, Format('trace:> [TWin32Object.ExtTextOut] DC:0x%x, X:%d,
Y:%d, Options:%d, Str:''%s'', Count: %d', [DC, X, Y, Options, Str,
Count]));
  //Check for opaque flag and buffer if there
  if ((Options and ETO_OPAQUE)  0) and Assigned(Rect) then
  begin
    //get DC objects
    OldBrush := SelectObject(DC, GetStockObject(NULL_BRUSH));
    OldPen := SelectObject(DC, GetStockObject(NULL_PEN));
    OldFont := SelectObject(DC, GetStockObject(DEFAULT_GUI_FONT));
    //reset DC objects
    SelectObject(DC, OldBrush);
    SelectObject(DC, OldPen);
    SelectObject(DC, OldFont);
    //Calculate relative size/pos
    bX := X - Rect^.Left;
    bY := Y - Rect^.Top;
    bWidth := Rect^.Right - Rect^.Left;
    bHeight := Rect^.Bottom - Rect^.Top;
    BufferDrawRect := Rect(0, 0, bWidth, bHeight);
    DrawRect := LPRECT(@BufferDrawRect);
    //Create buffer
    Buffer := CreateCompatibleDC(0);
    BufferBitmap := CreateCompatibleBitmap(0, bWidth, bHeight);
    SelectObject(Buffer, BufferBitmap);
    //get buffer objects and set DC objects
    OldBrush := SelectObject(Buffer, OldBrush);
    OldPen := SelectObject(Buffer, OldPen);
    OldFont := SelectObject(Buffer, OldFont);
    buffered := True;
  end else begin
    //Just use Defaults
    Buffer := DC;
    bX := X;
    bY := Y;
    If Asigned(Rect) then
      DrawRect := LPRect(DrawRect)
    else
      DrawRect := nil;
    buffered := False;
  end;
  //Perform Real ExtTextOut
  Result := Windows.ExtTextOut(Buffer, bX, bY, Options, DrawRect, Str,
Count, Dx);
  If Buffered then begin
    //Blt Buffer to screen
    Windows.BitBlt(DC, X, Y, bWidth, bHeight, Buffer, 0, 0, SRCCOPY);
    //reset buffer objects
    SelectObject(Buffer, OldBrush);
    SelectObject(Buffer, OldPen);
    SelectObject(Buffer, OldFont);
    //free bitmap and dc
    DeleteObject(BufferBitmap);
    DeleteDC(Buffer);
  end;
  Assert(False, Format('trace:< [TWin32Object.ExtTextOut] DC:0x%x, X:%d,
Y:%d, Options:%d, Str:''%s'', Count: %d', [DC, X, Y, Options, Str,
Count]));
End;

Reply by email

Micha Nelissen
Andrew Johnson wrote
First just commited a change to the GTK interface's ExtTextOut routine, which will now buffer Opaque text, so that the flickering caused by filling the bg before drawing the fg no longer happens, instead we only have flickering resulting from the drawing of the buffer itself.

Can you explain this a little more detailed? What is the cause of the flickering exactly? The win32 interface also has this problem.

Thanks,

Micha.

Reply by email

Andrew Johnson
Marc Weustink wrote 9 lines
>BeginPaint/EndPaint(or not returning handling things the same way), and >would require caching and keeping track of the extra info somehow, and >thus in all the win32 functions have offset functions to move to >relative position if a buffered dc(aka in the cache). Maybe this is too >complicated though... ?? I don't get the complete picture yet, but I do understand that if DoubleBuffering is moved to the interface, the win32 interface has to do the buffer itself, so it can't pass the native beginpaint.

hrmm I am not sure. this is really the problem - begin paint can pass a rect. if we are double buffering we should only create a buffer of the size of that rect, otherwise we waste memory. potentially quite a lot if say only a small portion of a large form is invalidated.

Which means that we would be dealing with a bitmap of smaller size and 0,0 origin, so calls to drawing primitives would need to know what the actual size of the buffer is and what the rect is, and adjust according to the top/left origin, i.e the rect passed is (25,25,40,40), so we get a bitmap of 15x15. so drawing functions would need to subtract 25 from the top and left.

If this kind of information can be gotten from the winapi great, but I don't think it can. you can't get the paintstruct of a dc afaik, so we need to have a cache of paintstructs, like a fast list of them keyed by the dc, so we can look up the dc in this cache in a function much like gtk DCOrigin, and if it finds a paintstruct keyed with that DC it returns the actual top/left. so drawing functions can addjust if the rect origin isn't 0,0.

but it would work sorta like

BeginPaint -> call win32 begin paint, create buffer, create temp things like actual buffer bitmap, cache passed paintstruct, hwnd, and buffer and "real" begin paint dc., returns buffer

arc -> getbufferorigin -> look up paintstruct in cache, get offset -> call win32 function offset to buffer

end paint -> look up cache to get "real" dc, bitblt buffer to real dc, get all info and delete temp stuff, remove paintstruct from cache, delete buffer, call win32 EndPaint

am I making any sense?

I haven't done all too much in depth thinking so I could be going too complicated.

This all means that the existing buffercode in the LCL should be (re)moved.

yeah some of it. most of it isn't ever used anyway.

Andrew

Reply by email

Marc Weustink
Andrew Johnson wrote 25 lines
On Fri, 2003-10-03 at 20:39, Marc Weustink wrote: > > Hmm.. indeed. First, where do we want doublebuffering to be handled. Should > it be part of the interface or should it be part of the LCL. > its a tricky question, because GTK2 automatically does doublebuffering, which means sometimes we have to manage it and do it ourselves. So on that note I would say defintely use or at least initiate it in the interface if at all possible. > When is it used ? Only while in the LM_PAINT message ? well it should be whenever it can be. No matter how its done in VCL :D In the VCL it is only handled in the paint message yes. In GTK2 its almost always used by default but because of the having to handle it ourselves for custom widgets then likely as far as its concerned it will also only be in the Paint message, however it is done from beginpaint/endpaint so anywhere that uses those functions will automatically get it in GTK2. So I suppose one way would be to make each interface BeginPaint always return a DoubleBuffer DC, and EndPaint bitblt it to the real one,

Exactly my thoughts. Thats why I asked where it was needed.

Show quoted text 10 lines
much like I am essentially doing for gtk2 by calling its own native begin and end paint methods. This would allow it to be done anywhere those functions are called, and since they should be being used by the LCL whenever a paint message doesn't pass its own DC that might allow us to do this. It would of course mean not actually using the native win32 BeginPaint/EndPaint(or not returning handling things the same way), and would require caching and keeping track of the extra info somehow, and thus in all the win32 functions have offset functions to move to relative position if a buffered dc(aka in the cache). Maybe this is too complicated though...

?? I don't get the complete picture yet, but I do understand that if DoubleBuffering is moved to the interface, the win32 interface has to do the buffer itself, so it can't pass the native beginpaint.

This all means that the existing buffercode in the LCL should be (re)moved.

Marc

Reply by email

Marc Weustink
Andrew Johnson wrote 29 lines
On Fri, 2003-10-03 at 14:43, Micha Nelissen wrote: > Can you explain this a little more detailed? What is the cause of the > flickering exactly? The win32 interface also has this problem. I am not sure its quite the same issue though it might be.. basically SynEdit calls ExtTextOut on each block of text, for instance on a line with Procedure MyFunction(someclass : TBlah); would call ExtTextOut something like 8 times. Now since SynEdit supports using a different background colour for each block of text, then this means ExtTextOut will get called with ETO_OPAQUE. This means that most of the time a block of text calls ExtTextOut, that block of text will get filled with the current brush before drawing the text. This means the text essentially disapears from the screen and then reapears. Since there are so many blocks this results in constant flashing all over the place every time something is invalidated. So in this case there are 8 potential flashes any time invalidate/repaint etc. What I have done in the GTK interface, is if ETO_OPAQUE is passed, I create a buffer pixmap of the size of the passed rectangle, and perform actual filling and drawing of text on that offset, then draw pixmap, meaning the block is drawn in one step to the screen. I don't know how easily this could be done in win32 since you would have to create a buffer hdc and hbitmap, calculate relative offsets, based on whether it was buffering or not, then draw to it, which also means possibly a fair bit more amount of memory needed etc.

You won't need this on win32, since it supports ExtTextOut natively :-) So it draws the text *with* background already.

Be aware that most win32 based interface calls don't need much translation. Especially for synedit, since in it's origin it was pure win32 based.

So don't try to mimic draw functs on win32 which are win32 native.

Marc

Reply by email

Mattias Gaertner

Hi all,

- improved codetools FPC source heuristic to handle the new chaotic directory structure
- implemented first refactoring tool: Edit -> Extract procedure
- implemented TRadioGroup.ColumnLayout
- Code Completion: "forward procedure completion" now adds bodies for all neighbour procedures too
- implemented Tools -> "Check LFM"
- implemented "Convert Delphi unit to Lazarus unit"
- added Delphi7 Source template
- fixed crash on fast closing two notebook pages
- fixed recreating handle of TNotebook
- implemented TPageControl, TTabSheet
based on TCustomNotebook and TCustomPage
- implemented TDBNavigator, TDBText, TDBEdit, TDBMemo, TDBImage, TDBListBox, TDBComboBox, TDBCheckBox, TDBRadioGroup, TDBCalendar, TDBGroupBox

Mattias

Reply by email

Andrew Johnson

Hey all,

First just commited a change to the GTK interface's ExtTextOut routine, which will now buffer Opaque text, so that the flickering caused by filling the bg before drawing the fg no longer happens, instead we only have flickering resulting from the drawing of the buffer itself.

This removes most of the constant flickering in the Source Editor, when for instance ctrl-mouse move on identifiers. This is mostly a workaround for the lack of Double-Buffering, and adds virtually no memory overhead or speed issues(or bugs) afaik.

Let me know if this causes issues for you, so I can find and resolve or if absolutely needed, revert.

Second, I have been commiting a few more CVS updates yesterday and today, which bring the GTK2 interface closer to useability, in fact the buffering changes I made for GTK I did in a GTK2 lazarus (painfully slow at points and buggy), and even ran a new app and rebuilt lazarus (still can't configure build options), it was only marginally crashy for basic things.

I have gotten a lot of the callbacks working to an extent, so hopefully once the Mouse Move point translation gets fixed, I will start moving the functions over to the GTK2 interface to help clean up the source code a bit more.

Already should be useable enough for those who want to help test and debug issues.

Andrew

Reply by email

Florian Klaempfl
to Mattias Gaertner: - improved codetools FPC source heuristic to handle the new chaotic directory structure -…
Mattias Gaertner wrote 7 lines
>So it should be correct, no? Looks correct. What is the include path for C:\pp\source\rtl\win32\sysutils.pp? (Source Editor -> PopupMenu -> UnitInfo)

c:\pp\source\rtl\objpas\;c:\pp\source\rtl\inc\;c:\pp\source\rtl\i386\;c:\pp\source\rtl\win32\;c:\pp\source\rtl\win32\;c:\pp\source\rtl\win32\i386\;C:\pp\source\rtl\win32\wininc\

Reply by email

Elio Cuevas Gómez
to Marc Weustink: It has been quiet a while and for a reason. The GTK keyboard event handling code is…
Marc Weustink wrote 9 lines
It seemed that I was looking at the wrong Lazarus instance :) Here it works, now some questions: - Can you type them in other controls or other apps - What platform, version etc. - What keyboard, language and font do you use - What do you want to type (and how) Marc

In other apps (mozilla):
�����
Yes, i can type them in other controls, such as the Object inspector. I tried to use a SynEdit, but Lazarus crashes when i close my project. I use Debian GNU/Linux Sarge and KDE 2.2
Lazarus is the latest CVS version.
My KB is a PC105 Spanish-Spain Font? I dunno, what is the defaulf font of the Lazarus editor.
I want accented chars such as ����� using the standard way (ie typing the ' and then the char). It works everywhere but the editor.

Elio Cuevas Gomez. There's not a better day than TODAY!

Reply by email

Mattias Gaertner
to Mattias Gaertner: - improved codetools FPC source heuristic to handle the new chaotic directory structure -…
Show quoted text 7 lines
Mattias Gaertner wrote: > Hi all, > > - improved codetools FPC source heuristic to handle the new chaotic > directory structure Hmm, still doesn't work for me :(:

The new heuristic is for the classes unit not the sysutils unit. Under Linux 1.0.11 seems to work. Also cross exploring the win32 sources under linux works.
Maybe it is a special win32 issue.

Show quoted text 20 lines
TPascalParserTool.BuildTree B OnlyIntf=TRUE C:\pp\source\rtl\win32\sysutils.pp ### TCodeToolManager.HandleException: "include file not found "sysutilh.inc"" at Line=27 Col=5 in "C:\pp\source\rtl\win32\sysutils .pp" Important part of env. options.xml: <FPCSourceDirectory Value="c:\pp\source\"> <History Count="5"> <Item1 Value="c:\fpc\fixes\fpc\"/> <Item2 Value="c:\pp\source\"/> <Item3 Value="c:\fpc\fixes\"/> <Item4 Value="c:\fpc\"/> <Item5 Value="C:\pp\source\Makefile.fpc"/> </History> </FPCSourceDirectory> So it should be correct, no?

Looks correct.

What is the include path for C:\pp\source\rtl\win32\sysutils.pp? (Source Editor -> PopupMenu -> UnitInfo)

Mattias

Reply by email

olivier GUILBAUD
to Marc Weustink: It has been quiet a while and for a reason. The GTK keyboard event handling code is…

Le Vendredi 17 Octobre 2003 23:05, Elio Cuevas G�mez a �crit :

> * All single byte input locales now generate a Keypress event. So > typing accented chars should work Acented chars don't work for me :-(

For me the acented chars work correctely but the numbers of the num pad keyboard dont work. With [NumLock] or not, the result is the same one.

Regards
Olivier

Reply by email

Marc Weustink
to Marc Weustink: It has been quiet a while and for a reason. The GTK keyboard event handling code is…
Andrew Johnson wrote
ah coolness. you broke GTK2 but not badly,

Oops

I changed your $IFdef GTK1 to $IFNDef GTK2_2, since to remove the X dependency _may_ require functions only in gtk2.2.

O joy not only differences in gtk 1 & 2 but also in 2 itself :(

In fact a few other functions in the interface still require X anyway unless this flag is passed during make.

Indeed, thats BTW why I converted X11Display to a function.

Nevertheless I believe the relevant API should be this in case you get a chance to look into it - http://developer.gnome.org/doc/API/2.0/gdk/gdk-Keyboard-Handling.html

I'm aware of that doc. I already have seen that some functs that I need from X are part of gtk2. Using those functions is one of the next steps.

Marc

Reply by email

marius popa
to Mattias Gaertner: - improved codetools FPC source heuristic to handle the new chaotic directory structure -…
Mattias Gaertner wrote 5 lines
Hi all, - improved codetools FPC source heuristic to handle the new chaotic - implemented "Convert Delphi unit to Lazarus unit"

Really usefull i think

- implemented TDBNavigator, TDBText, TDBEdit, TDBMemo, TDBImage, TDBListBox, TDBComboBox, TDBCheckBox, TDBRadioGroup, TDBCalendar, TDBGroupBox Mattias

Wow really nice TDB* components :)
Eager to test them ...

Reply by email

Andrew Johnson

I just tested out win32. It's flickering problem is a completely different issue, in fact, its the exact opposite problem. :)

the problem here is that afaict, the attempted double buffering code in the lcl is always happening, and instead of preventing flickering its causing even worse flickering. I tried disabling it for now with a BUFFERED_WMPAINT define, since it is never used in gtk interfaces, and it is causing such a mess in win32 anyway. If we figure out how to fix it properly we can re-enable the code by enabling this define at the top of Controls or removing the ifdef's entirely etc.

Andrew

Micha Nelissen wrote 18 lines
Andrew Johnson wrote: > First just commited a change to the GTK interface's ExtTextOut routine, > which will now buffer Opaque text, so that the flickering caused by > filling the bg before drawing the fg no longer happens, instead we only > have flickering resulting from the drawing of the buffer itself. Can you explain this a little more detailed? What is the cause of the flickering exactly? The win32 interface also has this problem. Thanks, Micha. _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives

Reply by email

Marc Weustink
to Marc Weustink: It has been quiet a while and for a reason. The GTK keyboard event handling code is…
Elio Cuevas G�mez wrote 16 lines
Marc Weustink wrote: > >It seemed that I was looking at the wrong Lazarus instance :) Here it >works, now some questions: >- Can you type them in other controls or other apps >- What platform, version etc. >- What keyboard, language and font do you use >- What do you want to type (and how) > >Marc In other apps (mozilla): ����� Yes, i can type them in other controls, such as the Object inspector. I tried to use a SynEdit, but Lazarus crashes when i close my project.

? works here

I use Debian GNU/Linux Sarge and KDE 2.2 Lazarus is the latest CVS version.

OK

My KB is a PC105 Spanish-Spain

OK

Font? I dunno, what is the defaulf font of the Lazarus editor.

Don't know. Not something I liked, so I choose another

I want accented chars such as ����� using the standard way (ie typing the ' and then the char). It works everywhere but the editor.

That should work. I rechecked it here.

Can you try my testapp ?

http://lazarus.dommelstein.net/test/KeyValue/project1

the upper 2 lines print out resp. the KeyDown and the KeyPress event. In the KeyPress event you should see the accented chars.

Marc

Reply by email

Elio Cuevas Gómez
to Marc Weustink: It has been quiet a while and for a reason. The GTK keyboard event handling code is…
Marc Weustink wrote 11 lines
Can you try my testapp ? http://lazarus.dommelstein.net/test/KeyValue/project1 the upper 2 lines print out resp. the KeyDown and the KeyPress event. In the KeyPress event you should see the accented chars. Marc

I rechecked too, all chars works OK in other controls, seems to be SynEdit specific.
CopyPasting accented chars works.
When i hit acent chars such ', ^, ", etc Your testapp shows "deadacute", "deadcircumflex", "deaddieresis" respectively, with a lot of other Extrange info ;-)

Elio Cuevas Gomez. There's not a better day than TODAY!

Reply by email

Marc Weustink
to Marc Weustink: It has been quiet a while and for a reason. The GTK keyboard event handling code is…
olivier GUILBAUD wrote 8 lines
Le Vendredi 17 Octobre 2003 23:05, Elio Cuevas G�mez a �crit : > > * All single byte input locales now generate a Keypress event. So > > typing accented chars should work > > Acented chars don't work for me :-( For me the acented chars work correctely but the numbers of the num pad keyboard dont work. With [NumLock] or not, the result is the same one.

Eeek, I see the correct values in the keypress event, but synedit (and synmemo) both seem to ignore that.
I'll have a look.

Marc

Reply by email

Marc Weustink

Hi,

It has been quiet a while and for a reason. The GTK keyboard event handling code is merely rewritten.

* Every key has now a unique VK_keycode, no matter what CTRL SHFT ALT combination is used, no matter what input locale is used

* All extra keys on a Microsoft Internet keyboard (or alike) generate a corresponding VK_keycode, they are passed through the KeyUp and KeyDown events

* All single byte input locales now generate a Keypress event. So typing accented chars should work

* CTRL-@ through CTRL-Z now also generate a Keypress event with #0..#26 as char

Ok that were the good things, now the known issues

First a general remark on VK_keycodes. VK_keycodes are only exactly defined for the keys A-Z and 0-9.
On western keyboards, the A-key generates a VK_A, the B-key a VK_B etc. On non western keyboards the VK_A etc. is still generated. Only now we have to map a character to a VK_Keycode. If a layout is conclusive, the generated VK_keycodes are constant.
In all other cases a VK_keycode is generated and it might differ, based on keyboard, (X)window server and platform

+ Dead keys:
Dead keys aren't completely supported. They will generate a keypress but won't always generate a KeyUp and KeyDown. Even worse on some keyboard layouts and/or on some X servers a dead char is mapped to a 'virtual' (IE, not on your keyboard) key or to an existing non dead key. In those cases a wrong VK_Keycode may be passed to Keyup and KeyDown

+ Cyrillic keyboards:

I've found 2 complete different layouts.
VK_A on a russian layout generates a cyrillic_EF
VK_A on a serbian layout generates a cyrillic_A

Since mapping cyrillic_A to VK_A is easier so that encoding is used.

+ UTF8:
UTF8 and other multibyte character encodings aren't supported (yet). The editor won't draw then anyway.

+ Added more X dependency, so the gtk-win32 is a bit broken now. I still have to implement the missing parts yet.

+ VK_IRREGULAR is gone (every key has an uniqe VK_ so it was obsolete)

This al is tested on the following layouts/languages: US, Arabic, Czech, Russian, Greek, Thai (and some others)

As reference on layouts etc. I used
http://www.microsoft.com/globaldev/reference/keyboards.aspx and the Microsoft Keyboard Layout Creator

Have fun, and please report me if there is something broken.

Marc

Reply by email

Andrew Johnson
to Marc Weustink

ah coolness. you broke GTK2 but not badly, I changed your $IFdef GTK1 to $IFNDef GTK2_2, since to remove the X dependency _may_ require functions only in gtk2.2. In fact a few other functions in the interface still require X anyway unless this flag is passed during make. Nevertheless I believe the relevant API should be this in case you get a chance to look into it -

http://developer.gnome.org/doc/API/2.0/gdk/gdk-Keyboard-Handling.html

Andrew

Marc Weustink wrote 69 lines
Hi, It has been quiet a while and for a reason. The GTK keyboard event handling code is merely rewritten. * Every key has now a unique VK_keycode, no matter what CTRL SHFT ALT combination is used, no matter what input locale is used * All extra keys on a Microsoft Internet keyboard (or alike) generate a corresponding VK_keycode, they are passed through the KeyUp and KeyDown events * All single byte input locales now generate a Keypress event. So typing accented chars should work * CTRL-@ through CTRL-Z now also generate a Keypress event with #0..#26 as char Ok that were the good things, now the known issues First a general remark on VK_keycodes. VK_keycodes are only exactly defined for the keys A-Z and 0-9. On western keyboards, the A-key generates a VK_A, the B-key a VK_B etc. On non western keyboards the VK_A etc. is still generated. Only now we have to map a character to a VK_Keycode. If a layout is conclusive, the generated VK_keycodes are constant. In all other cases a VK_keycode is generated and it might differ, based on keyboard, (X)window server and platform + Dead keys: Dead keys aren't completely supported. They will generate a keypress but won't always generate a KeyUp and KeyDown. Even worse on some keyboard layouts and/or on some X servers a dead char is mapped to a 'virtual' (IE, not on your keyboard) key or to an existing non dead key. In those cases a wrong VK_Keycode may be passed to Keyup and KeyDown + Cyrillic keyboards: I've found 2 complete different layouts. VK_A on a russian layout generates a cyrillic_EF VK_A on a serbian layout generates a cyrillic_A Since mapping cyrillic_A to VK_A is easier so that encoding is used. + UTF8: UTF8 and other multibyte character encodings aren't supported (yet). The editor won't draw then anyway. + Added more X dependency, so the gtk-win32 is a bit broken now. I still have to implement the missing parts yet. + VK_IRREGULAR is gone (every key has an uniqe VK_ so it was obsolete) This al is tested on the following layouts/languages: US, Arabic, Czech, Russian, Greek, Thai (and some others) As reference on layouts etc. I used http://www.microsoft.com/globaldev/reference/keyboards.aspx and the Microsoft Keyboard Layout Creator Have fun, and please report me if there is something broken. Marc _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives

Reply by email

Florian Klaempfl
to Mattias Gaertner: - improved codetools FPC source heuristic to handle the new chaotic directory structure -…
Mattias Gaertner wrote
Hi all, - improved codetools FPC source heuristic to handle the new chaotic directory structure

Hmm, still doesn't work for me :(:

TPascalParserTool.BuildTree B OnlyIntf=TRUE
C:\pp\source\rtl\win32\sysutils.pp
### TCodeToolManager.HandleException: "include file not found "sysutilh.inc"" at Line=27 Col=5 in "C:\pp\source\rtl\win32\sysutils .pp"

Important part of env. options.xml:

<FPCSourceDirectory Value="c:\pp\source\">
<History Count="5">
<Item1 Value="c:\fpc\fixes\fpc\"/>
<Item2 Value="c:\pp\source\"/>
<Item3 Value="c:\fpc\fixes\"/>
<Item4 Value="c:\fpc\"/>
<Item5 Value="C:\pp\source\Makefile.fpc"/>
</History>
</FPCSourceDirectory>

So it should be correct, no?

Reply by email

Marc Weustink
to Marc Weustink: It has been quiet a while and for a reason. The GTK keyboard event handling code is…
Elio Cuevas G�mez wrote 11 lines
Marc Weustink wrote: > >Can you try my testapp ? > >http://lazarus.dommelstein.net/test/KeyValue/project1 > >the upper 2 lines print out resp. the KeyDown and the KeyPress event. In >the KeyPress event you should see the accented chars. > >Marc
I rechecked too, all chars works OK in other controls, seems to be SynEdit specific. CopyPasting accented chars works.

It's not SynEdit specific, but the other controls are gtk native. They handle the gtk events themselves and present the correct chars.

When i hit acent chars such ', ^, ", etc Your testapp shows "deadacute", "deadcircumflex", "deaddieresis" respectively, with a lot of other Extrange info ;-)

Line1: Keydown event receiced by the form
Line2: Keypress event received by the form
Line3: the gtk keyevent (thats where you read the "deadacute" etc) Line4: all chars (=keysyms) possible given a certain key (=keycode) Line5: all keycodes of keys currently pressed

But what does it say when you press 'e ?

Marc

Reply by email

Marc Weustink
to Marc Weustink: It has been quiet a while and for a reason. The GTK keyboard event handling code is…
olivier GUILBAUD wrote 8 lines
Le Vendredi 17 Octobre 2003 23:05, Elio Cuevas G�mez a �crit : > > * All single byte input locales now generate a Keypress event. So > > typing accented chars should work > > Acented chars don't work for me :-( For me the acented chars work correctely but the numbers of the num pad keyboard dont work. With [NumLock] or not, the result is the same one.

Fixed.

I didn't realize that the keypad keys have 2 VK_codes (movement and numbers), so I reported only the movement codes independent of [numlock]. I also noticed that shift also switches between the two. In those cases shift shouldn't be marked as pressed. This is also fixed.

Marc

Show quoted text 7 lines
Regards Olivier _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives

Reply by email

Andrew Johnson
to Mattias Gaertner: - improved codetools FPC source heuristic to handle the new chaotic directory structure -…

I tested it out as well, and it simply will not find includes in win32. finds the .pp/.pas files themselves, but not the .inc. So something needs to be fixed, but not sure what, or where to look.

Andrew

Mattias Gaertner wrote 50 lines
On Thu, 16 Oct 2003 00:24:39 +0200 Florian Klaempfl wrote: > Mattias Gaertner wrote: > > Hi all, > > > > - improved codetools FPC source heuristic to handle the new chaotic > > directory structure > > Hmm, still doesn't work for me :(: The new heuristic is for the classes unit not the sysutils unit. Under Linux 1.0.11 seems to work. Also cross exploring the win32 sources under linux works. Maybe it is a special win32 issue. > TPascalParserTool.BuildTree B OnlyIntf=TRUE > C:\pp\source\rtl\win32\sysutils.pp > ### TCodeToolManager.HandleException: "include file not found > "sysutilh.inc"" at Line=27 Col=5 in "C:\pp\source\rtl\win32\sysutils > .pp" > > Important part of env. options.xml: > > <FPCSourceDirectory Value="c:\pp\source\"> > <History Count="5"> > <Item1 Value="c:\fpc\fixes\fpc\"/> > <Item2 Value="c:\pp\source\"/> > <Item3 Value="c:\fpc\fixes\"/> > <Item4 Value="c:\fpc\"/> > <Item5 Value="C:\pp\source\Makefile.fpc"/> > </History> > </FPCSourceDirectory> > > > So it should be correct, no? Looks correct. What is the include path for C:\pp\source\rtl\win32\sysutils.pp? (Source Editor -> PopupMenu -> UnitInfo) Mattias _________________________________________________________________ To unsubscribe: mail with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives

Reply by email

Marc Weustink
to Marc Weustink: It has been quiet a while and for a reason. The GTK keyboard event handling code is…
Elio Cuevas G�mez wrote 15 lines
Marc Weustink wrote: >Can you try my testapp ? > >http://lazarus.dommelstein.net/test/KeyValue/project1 > >the upper 2 lines print out resp. the KeyDown and the KeyPress event. In >the KeyPress event you should see the accented chars. > >Marc I rechecked too, all chars works OK in other controls, seems to be SynEdit specific. CopyPasting accented chars works. When i hit acent chars such ', ^, ", etc Your testapp shows "deadacute", "deadcircumflex", "deaddieresis" respectively, with a lot of other Extrange info ;-)

Can you check it again with my testapp (there is a newer version) with logging enabled and can you send me the output when you try to create an accented char ?

Marc

Reply by email

Marc Weustink
to Marc Weustink: It has been quiet a while and for a reason. The GTK keyboard event handling code is…
you wrote 11 lines
At 23:05 17-10-2003, Elio Cuevas G�mez wrote: >>* All single byte input locales now generate a Keypress event. So typing >>accented chars should work > >Acented chars don't work for me :-( Hmmm... just tried it with a testapp and there it works. However the lazarus editor doesn't :( I'll look at it

It seemed that I was looking at the wrong Lazarus instance :) Here it works, now some questions:
- Can you type them in other controls or other apps
- What platform, version etc.
- What keyboard, language and font do you use
- What do you want to type (and how)

Marc

Reply by email