Hi,

don't know how old this change (probably a week or so), but TLMMouseEvent in svn now lacks state field and first what stopped compiling is VirtualTree port with CMMouseWheel method (VirtualTrees.pas(15137,71) Error: Identifier not found "State"). Was such sensitive change intentional and unavoidable?

Thanks

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111027/7b2ffcd8/attachment.html>

2011/10/27 Max Vlasov :

don't know how old this change (probably a week or so), but TLMMouseEvent in svn now lacks state field

http://wiki.lazarus.freepascal.org/Lazarus_0.99.0_release_notes#Support_for_the_shift_states_ssCaps.2C_ssNum_and_ssScroll_was_removed._TLMMouseEvent.State_was_removed.

and first what stopped compiling is VirtualTree port with CMMouseWheel method (VirtualTrees.pas(15137,71) Error: Identifier not found "State").

It compiles fine if you do "svn update" on it.

On Thu, Oct 27, 2011 at 12:06 PM, Felipe Monteiro de Carvalho <

Thanks, but the svn link

https://lazarus-ccr.svn.sourceforge.net/svnroot/lazarus-ccr/components/virtualtreeview-new/ listed at
http://wiki.lazarus.freepascal.org/VirtualTreeview

don't update anything, the date of last change is something in 2010 should I use some another branch?

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111027/38180faf/attachment.html>

2011/10/27 Max Vlasov :

don't update anything, the date of last change is something in 2010 should I use some another branch?

Ok, I had fixed the older version ... now I fixed this one too.

On Thu, Oct 27, 2011 at 12:29 PM, Felipe Monteiro de Carvalho <

Thanks, Felipe, worked like magic

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111027/f8d108ef/attachment.html>

It is also relevant to note that it is rather messy like it is now, with 2 versions of TreeView in the Lazarus-CCR being that the newer one depends on an external package ... the external package should be moved to the CCR or copied there for private use of the VirtualTreeView, and the older one removed.

Or maybe VTV should be moved inside Lazarus?

Alexander Klenin wrote

Or maybe VTV should be moved inside Lazarus?

Well, yes, that is a very strong possibility. I need a VTV inside customdrawn package. I just worry what kind of dependencies this VTV might have, I'd like something really portable and as compatible as much as possible with TTreeView. It must also be skinnable, but that can be altered if necessary.

That's why I insist on adding missing routines from delphicompat package to lclintfs. They are usefull + one more routine widely used by 3rd party components on delphi : Canvas.BrushCopy

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111027/42aae651/attachment.html>

zeljko wrote

That's why I insist on adding missing routines from delphicompat package to

Should be "That's why I insisted ..."

zeljko

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111027/b7fd1db8/attachment.html>

Hello,

Ok, Luiz, since you are in the discussion, I have some questions:

1> How compatible is VTV with TTreeView. Does it implement everything that TTreeView supports?

2> It seams to require something like OleUtils, is it heavy on OS dependencies?

3> How much does it require from the LCL? Does it simply base on TCustomControl / TCanvas and use that or does it go on to use a lot of other stuff from the LCL?

Luiz Americo Pereira Camara wrote

- The old port was developed by christian, but had some limitations that would lead to much work to be fixed (more than a new port)

What kinds of limitations? I wonder now if it is a better base for what I need.

I need a custom drawn clone of TTreeView.

I for one use the VTV for an application on MAC and the code for VTV-new does not compile out-of-the-box on a MAC since some include files does not exists MAC (i cannot remember which though).
So I've had to create some empty files which in my case luckyli is not Bonde Christiansen.

I meant, only routines which are needed by VTV pass to widgetset, so VTV maintaining is easier.btw. VTV can be base for TTreeView, some time ago I've tried that and it was fine .. you have TTreeView but under that is VTV. In any case - it's not important for me. I'm using VTV with delphicompat and no single change will disturb me.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111027/d023f445/attachment.html>

I've already written about it in my previous mail. It's not so hard to get VTV as base for TTreeView, of course TTreeView needs some changes, but for user it's same. TTreeNodes are mapped to VTV nodes and that's it.

zeljko

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111027/e35dfba3/attachment.html>

2011/10/27 zeljko :

I've already written about it in my previous mail. It's not so hard to get VTV as base for TTreeView, of course TTreeView needs some changes, but for user it's same. TTreeNodes are mapped to VTV nodes and that's it.

That's very interresting, but I still have a dilema. I wonder if starting from zero is easier or if modifying VTV to meet my requirements is easier.

Unfortunatelly, nearly each and everytime I've had this dilema I started modifing someoneelse's code just to find out that if I had started from zero it would have been way faster and easier...

It's all history:

- The old port was developed by christian, but had some limitations that would lead to much work to be fixed (more than a new port)
- So i started a new port in another repository (at the time BountySource)
- In 2007, in a discussion with Vincent Snjiders he asked to mirror in Lazarus-CCR.
- To avoid the extra work i decided to move entirely to CCR with the condition to be in charge of the direction of the port. The dependency kept in my repo (no special reason)

So, my position:

- Delete the old VTV and update the wiki: ask christian
- Move the lclextensions to CCR: no problem
- Move VTV to Lazarus: not now, it would open a can of worms. Believe me.
- Changes like Felipe one is welcome but i'd like to be at least informed. It's a rule of Lazarus-CCR government that each one stay with your projects

BTW: VTV trunk is unstable and buggy given the introduction of (unfinished) features and incompatibilities in the Delphi repository. The actively developed with stable API and with many bug fixes is the 4.8 branch.

Luiz

zeljko wrote

That's why I insist on adding missing routines from delphicompat package to lclintfs.

Maybe some, certainly not all. Some are very windows centric.

delphicompat is meant to be a bridge to port components.

- Port to LCL with help of DelphiCompat -> will work on windows but with some missing functionality in other widgetsets
- Detect and remove gradually delphicompat dependency

Luiz

Felipe Monteiro de Carvalho wrote

On Thu, Oct 27, 2011 at 11:23 AM, Alexander Klenin wrote: I'd like something really portable and as compatible as much as possible with TTreeView.

As being portable i cant agree more. The way to go is remove missing DelphiCompat dependency. Is there a tool that detect only what procedures are being used from a unit? So we can list the remaining DelphiCompat dependency

As being compatible to TTreeView i have my doubts, they are different beasts. VTV has a different paradigma and that is that makes useful.

Luiz

Felipe Monteiro de Carvalho wrote

Hello, Ok, Luiz, since you are in the discussion, I have some questions:

Hi, i'm in a hurry now. I will answer in a few hours

Luiz

2011/10/27 Max Vlasov :

Was such sensitive change intentional and unavoidable?

The change is not really sensitive, user controls should handle OnMouseWhell. I don't know why VTV uses the lower level event, it would be interresting to hear why. Probably just because the original was done in Delphi, where people depend on Windows-specific events.

Now I don't understand. That change was maded for delphi compatibility or not ? VTV had State in that message and checked it. Ok, it checked for shift or ctrl, so easy to exchange with Button.
Now non-understandable part:
If noone from lcl comunity (eg Luis) changed that code, that means that such code is there from original source , VTV is written with delphi and that means that such msg have State.
So if original win msg have State , why it's removed and why it's changed to Button now ?

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111027/0e1175c7/attachment-0001.html>

2011/10/27 zeljko :

Now I don't understand. That change was maded for delphi compatibility or not ? VTV had State in that message and checked it. Ok, it checked for shift or ctrl, so easy to exchange with Button.

TLMMouseEvent does not exist in Delphi AFAIK

Felipe Monteiro de Carvalho wrote

TLMMouseEvent does not exist in Delphi AFAIK

My original remark was supposed to be understook like that: the original Delphi component probably handles the Windows API message WM_MOUSEWHELL or something like that. So Luiz substituted that with a LCL event handling, instead of just going with OnMouseWhell

On Thu, Oct 27, 2011 at 5:43 PM, Felipe Monteiro de Carvalho <

Just looked, the original had
TBaseVirtualTree.CMMouseWheel(var Message: TCMMouseWheel);message CM_MOUSEWHEEL;

TCMMouseWheel of Delphi has ...ShiftState: TShiftState;

looking at TLMMouseEvent, shift is last (ShiftState in delphi is not) so probably the one who ported it, also added the field to the lazarus record just for this case. If so, I agree this is a good change to remove field added previously just for one particular component. Maybe Luiz later will add some details.

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111027/2d71d4ba/attachment.html>

2011/10/27 Max Vlasov :

oh crap =D

But anyway, thats totally different from our event:

http://docwiki.embarcadero.com/VCL/en/Controls.TCMMouseWheel

Which saves the day for me.

2011/10/27 zeljko :

So if original win msg have State , why it's removed and why it's changed to Button now ?

This idea was from the original patch sender ...

Maybe it was not good after all. But on one side it is good, because now LCL widgetsets are forced to use ShiftStateToKeys, and that will kill any non standard ShiftStates. ssCaps is declared in the RTL, so we can't undeclare it, so someone could try to send it to the LCL. Now we force its removal, because there is no way to fit it into the Button.

Part of the fix was exactly killing this unreliable events. In Windows you would get ssCaps when caps lock=on, not when it is pressed, which was totally wrong. In other platforms you could receive part or none of them. It was a mess.

I don't understand this change:

gtk2callback.inc:

@@ -2900,7 +2898,7 @@
   ShiftState := GTKEventStateToShiftState(Event^.State);

if (KCInfo.Flags and KCINFO_FLAG_SHIFT_XOR_NUM 0)
- and ((ssShift in ShiftState) xor (ssNum in ShiftState))
+ and (ssShift in ShiftState)

   then VKey := KCInfo.VKey2
   else VKey := KCInfo.VKey1;

and similar in gtk2proc.inc.

I would think this code checked if shift is pressed and numlock off or shift not pressed and numlock on. Now checking numlock has been removed completely. Shouldn't this now be something like: (ssShift in ShiftState) xor IsNumLockOn?

gtk2proc.inc:
@@ -3124,8 +3124,8 @@

   const
     STATE_NAME: array[TShiftStateEnum] of String = ('ssShift',

'ssAlt', 'ssCtrl',
'ssLeft', 'ssRight', 'ssMiddle', 'ssDouble',
- 'ssMeta', 'ssSuper', 'ssHyper', 'ssAltGr', 'ssCaps', 'ssNum',
- 'ssScroll', 'ssTriple', 'ssQuad', 'ssExtra1', 'ssExtra2');
+ 'ssMeta', 'ssSuper', 'ssHyper', 'ssAltGr',
+ 'ssTriple', 'ssQuad', 'ssExtra1', 'ssExtra2');

   {$endif}
   var

This won't compile because TShiftStateEnum has not changed in RTL.

cobines wrote

I don't understand this change:

ops, these wrong changes ... but I'm not in Linux now. Can you send a patch which fixes it?

Hans-Peter Diettrich wrote

The LCL has no (usable) interface for virtual trees, lists or tabs.

That's what I am trying to fix ;)

I am (very slowly) writing a custom drawn set of controls.

Contributors are welcome, just send me patches which implement stuff into components/customdrawn/

The skeleton of TTabControl and TPageControl are finished there, and they even have property editors and can be installed in the IDE, but the only skin available at the moment is a basic WinCE skin.

Skins are welcome =) Skins are implemented in Pascal and should immitate existing systems.

Again I suggest to provide two interfaces for the ComCtrls, one with full Delphi compatibility (usable for virtual trees etc.), and a portable version, useful also with other than Win32 widgetsets.

There are already 2 interfaces:

1 -> The current native version
2 -> TCDPageControl and friends in the customdrawncontrols.pas unit

See:
http://wiki.lazarus.freepascal.org/Lazarus_Custom_Drawn_Controls http://wiki.lazarus.freepascal.org/Lazarus_Custom_Drawn_Package

Luiz Americo Pereira Camara wrote

Is not TTreeView custom draw?

Ha, it seams that yes, so 1 less to implement =D

I mixed it up with TListView... TListView is one which I really need a custom drawn version because the native is not very good and it is a quite complex control to implement =(

cobines wrote

I don't understand this change:

Ok, I reverted the wrong stuff from gtk2 in rev 33111 ... also fixing in gtk 1 now

The LCL has no (usable) interface for virtual trees, lists or tabs.

Again I suggest to provide two interfaces for the ComCtrls, one with full Delphi compatibility (usable for virtual trees etc.), and a portable version, useful also with other than Win32 widgetsets.

DoDi

I dont use TTreeView but probably VTV can do all that TTreeView does although with different approach. Typically doing simple things with VTV requires more code/knowledge but in the other side as soon you master it's possible to do complex things. See screenshot. It has a steep learning curve.

2> It seams to require something like OleUtils, is it heavy on OS dependencies?

Yes. In fact, obviously uses OLE only under Win32

3> How much does it require from the LCL?

It's heavy dependent of winapi/LCLIntf. It takes windows api to its limits

Does it simply base on TCustomControl / TCanvas and use that or does it go on to use a lot of other stuff from the LCL?

See above.

AFAIK TTreeView is all customdraw

Luiz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vtv.png
Type: image/png
Size: 20568 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111027/3ecd9730/attachment-0001.png>

Basically it commented all code that did not work with LCL/Lazarus

I took a different approach: as soon a LCL bug/limitation was faced i reported to bugtracker sometimes with patches. Most of the bugs i reported was because of this port:
http://bugs.freepascal.org/view_all_set.php?type=1&temporary=y&reporter_id=34 . It took a long time but in the end i (we) got a better VTV and LCL.

I need a custom drawn clone of TTreeView.

Is not TTreeView custom draw?

Luiz

As far as i remember, i did not change the LCL.

I adapted the Delphi code from what LCL provided. I will investigate further the reasons i choose.

Luiz

2011/10/27 Felipe Monteiro de Carvalho :

OK, thanks.

I also couldn't find this one.

The WM_MOUSEWHEEL has the buttons encoded in the low word of wParam, so that "Buttons" is a descriptive Name, different from "State" or "Shift" in other messages with both buttons and modifier keys encoded in wParam.

DoDi

On Thu, Oct 27, 2011 at 5:37 PM, Hans-Peter Diettrich wrote: > The LCL has no (usable) interface for virtual trees, lists or tabs.

[...]

There are already 2 interfaces: 1 -> The current native version 2 -> TCDPageControl and friends in the customdrawncontrols.pas unit

I'm not sure whether you got the difference between custom drawn and virtual trees/list - both features are unrelated.

DoDi

Hans-Peter Diettrich wrote

I'm not sure whether you got the difference between custom drawn and virtual trees/list - both features are unrelated.

You are correct about TTreeView, I wrongly mixed it here ...

But about TListView, not, I had serious problems with this component across platforms which basically cannot be solved without a custom drawn TListView.

Hello,

I reverted large parts of the change in rev 33114, because I decided to avoid this backwards compatibility break and keep more Delphi-like.

Sorry for the mess, I'll try to be more careful when aplying patches in the future =(

I added a new solution: Just remove ssCaps and friends if the widgetset adds them.

Luiz, could you revert my changes to the VTV?

Sure.

Luiz

Ops...

I forgot that my trunk copy is switched to branch 4.8, so to change it i would need to undo the switch and redo it again

Can you revert?

Luiz

I can imagine easily that other widgetsets cannot provide all the view modes of an Windows ListView, without much special drawing in the LCL or interface. In so far it looks like a good idea to implement an owner drawn version, and to provide one such handler for the non-ownerdrawn version.

DoDi

Luiz Americo Pereira Camara wrote

Can you revert?

Done

Felipe Monteiro de Carvalho wrote

I am (very slowly) writing a custom drawn set of controls.

Consider saying goodbye to about 4 years of your life. :) Wouldn't it simply be easier to work on LCL-fpGUI widgetset interface instead?

From your posts of the last few months I have noticed you seem to like

customdrawn components more and more. Maybe now you understand my view with fpGUI. ;-) For cross platform apps, or for total flexibility, you can't beat customdrawn components.

May I ask why you have a sudden interest in customdrawn components? Just to have them for LCL, or is there some specific project they are required for?

Graeme Geldenhuys wrote

Wouldn't it simply be easier to work on LCL-fpGUI widgetset interface instead?

LCL-fpGUI looks very promising, indeed !

I would appreciate improvements on LCL-fpGUI a lot. If anybody starts working on same, I might be able to supply some suggestions and do some tests. (A testing program showing some issues of LCL/fpGUI with threading support already is available.)

In fact, it would be nice to have a well defined "layer" in such a "WidgetType" for customdrawn components, that allows switching between multiple sets of actual drawing functions, keeping the LCL-near stuff in a common set of files, while each "Layout" is done in another set of files. (This would on the long run even allow for creating a set of layout functions that works remotely via some data channel (such as (a) "ifi": remote drawing functions done in FPC or (b) HTTP / remote drawing functions done in Javascript or (c) some local interface within Android / drawing functions done in Java using the standard Android Library).

I suppose the "fpGUIPlatform" variable for the build process already is a draft of such a layer-switch.

-Michael

Felipe Monteiro de Carvalho wrote

http://wiki.lazarus.freepascal.org/Lazarus_Custom_Drawn_Controls http://wiki.lazarus.freepascal.org/Lazarus_Custom_Drawn_Package

In fact I understand that fpGUI already is a custom drawn Widget set and it does work (to some extend) with Lazarus and (optionally, partly) is integrated in the LCL.

The tests I did are in fact promising. So I don't see that it is viable to start another independent project that deals with custom drawn components.

-Michael

Graeme Geldenhuys wrote

Consider saying goodbye to about 4 years of your life. :) Wouldn't it simply be easier to work on LCL-fpGUI widgetset interface instead?

Easier, maybe yes, but:

* Part of the work is to build controls to use the existing LCL apps. I need a custom drawn TTrackBar with a special skin, a custom drawn TListView and other punctual components. A new widgetset would be all or nothing, then my applications won't work until it is totally finished, but I need them now for some concrete projects... and I also need the skinning capability... summing up I need many TCD* components anyway regardless of any custom drawn widgetset.

* Part of this work is aimed at making it easier to port the LCL. If I write LCL-fpgui I won't solve my problem. I'll have to port fpgui instead for new platforms. That's a huge complicator, I can't imagine how I could port fpgui to Android, I suppose that would be extremely difficult for me to adapt fpgui to atend all the particularities of the platform, but I already know the LCL very well, so here I already know everything that I need to do.

But I am not worried if it turns out to be too big of a task for me, my controls can be used in existing LCL widgetsets, so my work won't be wasted. I took care of choosing the architecture very well.

Short story: Microsoft killing Windows Mobile was the big motivator

Actually I have since years wanted to do this, but I simply gave up on the whole idea considering it too big of a task for many years. Then I worked a lot on LCL-WinCE and what happened in the end? It was much, much worse then if I had started a custom drawn widgetset from the start. People running Microsoft (and Apple and even Ubuntu) are totally despisable. Microsoft didn't even blink while killing years of work that I put into LCL-WinCE. Apple killed Carbon and the Ubuntu guys have fun adding unfinished features that break Gtk2 apps.

Writing code for APIs created by those guys is what I call putting years in the trash bin. Writing a custom drawn set of controls is something they cannot kill that easily. It will last as long as native code exists, and even in the case of a move like Microsoft did you still didn't waste that much time, all the generic work is preserved and can be reused in another platform.

Native look? I couldn't care any less each day that passes with Microsoft pushing Ribbons, which actually are already obsoleted by Metro =D It is a jungle. They change their native look every couple of years. Not to mention how html apps are getting more fashionable, you can't get any less native then that. But people that want native look can always write skins.

All I want is to be able to port the LCL to new platforms with a minimum of work and with a minimum of time loss when whatever bigshot director trashes the platform that I am working with now. And custom drawn is the way to go, there is no doubt about that.

+1

I'll join that as soon as we release laz 1.0.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111028/36ac5148/attachment-0001.html>

Felipe Monteiro de Carvalho wrote

And custom drawn is the way to go, there is no doubt about that.

+1
I have said that for years, but so many kept arguing with me. :) In fact custom drawn widgets are much less work in the long run, and much less workarounds.

In fact I agree with pretty much everything you said in your reply. :) Web apps, various mobile phone interfaces, even OS X and Windows don't have consistent "native looks". Everybody is skins/themes crazy. Our customers never once complained about our fpGUI-based apps not looking as everything else - simply because not everything else looks the same either. As long as functionality and user experience is similar, that is all they need to get their job done!