TScroollBar vs TControlScrollBar

[simsee]

I have a doubt about the scrollbars. LCL implements this type of control with two distinct classes.

The first is the TScrollBar class, the second is the TControlScrollBar class. If I understand correctly, the latter is used in TScrollingWinControl type controls, such as TScrollBox, but it is less rich than the former, which allows for finer management. In particular it does not contain event handlers, including OnChange and OnScroll.

Given this, how can I detect slider motion in a TScrollBox control? Should I use a TWinControl control and combine it with two TScrollBars?

[jamie]

When the widget is working properly, which in your case I don't think it is, there should be a LM_VSCROLL or LM_HSCROLL message posted to the control.

 Take it from there.

[simsee]

Thanks, but how can I get these messages?  Is it a cross platform solution?

[jamie]

Code: Pascal  [Select][+][-]

1. unit Unit1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. uses
8.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs,Lmessages, StdCtrls;
9.  
10. type
11.   TScrollBox = Class(Forms.TScrollBox)
12.     Procedure WndProc(Var M:TLmessage) override;
13.   end;
14.  
15.   { TForm1 }
16.  
17.   TForm1 = class(TForm)
18.     ScrollBox1: TScrollBox;
19.   private
20.  
21.   public
22.  
23.   end;
24.  
25. var
26.   Form1: TForm1;
27.  
28. implementation
29.  
30. {$R *.lfm}
31. Procedure TScrollBox.WndProc(var M:TLmessage);
32. Begin
33.   Case M.Msg of
34.     LM_VSCROll:Beep;
35.     LM_HSCROLL:Beep;
36.   end;
37.  Inherited;
38. end;
39.  
40. end.
41.  
42.  

[simone]

Nice example of interposer (aka interceptor) class trick, combined with protected hack

[simsee]

Thanks Jamie.

Is the approach you suggest cross platform? Isn't there a higher level solution? Curious that the TScrollBox control does not have a handler for scrollbar events (as in TControlScrollBar).

[jamie]

Lazarus allows you to make your own controls and install them so you can drop them on the form.
You can in theory take what I showed you and build on it for a new control.

As for what I showed you being cross platform, did you try it?

and what makes you think that is low level?

[simsee]

I haven't tried it because at the moment I only have Windows available. Otherwise I wouldn't have asked (twice, with no response).

Using messages to handle GUI events doesn't seem like the usual approach to me. I don't think GUI applications typically use LMessages unit. This is why I talk about a low-level solution, to be taken in a broad sense.

[jamie]

Not message based.

I think you'll find the majority of controls and forms are all message based.

Infact, most of the infrastructure is built around it.

Using the Lmessages simply means the messages that are supported across the pond.

So you have LCLIntf, LCLtype, Types etc. that contain the cross platform items.

The Widgets in the LCL capture the message handling first and some of the messages may not make it to the forms or controls, however, it does not mean you can't intercept them. The window procedure is part of the structure , too.

[TRon]

I think you'll find the majority of controls and forms are all message based.

Infact, most of the infrastructure is built around it.

for TS: In fact all traditional GUI's are implemented that way (blame the OS developers). With a message pump loop in the main application/form that divert the messages to the underlying controls (if an application wishes/decides to do so).

Using the Lmessages simply means the messages that are supported across the pond.

Indeed.

[simsee]

Thank you for the explanations.

I was aware that there are these types of messages behind the scenes. I believe they are not used explicitly in common applications, but almost always only in the implementations of the different widgets.

Since from the (superficial...) analysis of LMessages unit I saw references to Windows OS, I had some doubts about portability across platforms.

[TRon]

@simsee:
That is the beauty of a rad. It abstracts all that boring message handling stuff away. You can still write traditional windows programs for example, where you need to do/process everything manually.

So, usually you do not notice that this is being done behind the scenes but once in a blue moon you come across a functionality that a certain control lacks that you wish it would have that feature. Depending on what feature exactly you wish to implement for such a control it is possible to have to use messages in order to be able to accomplish that goal. Jamie's example being one of them.

whenever you see message starting with the letters WM, then you need to start worrying because those are windows specific messages (though in order to stay on par with Delphi most wmXXX named messages are coupled with their lmXXX names counterpart.

[simsee]

I really appreciate your explanations. But can you simply tell me, to conclude, whether the management of scrollbar events in a Scrollbox proposed by Jamie is cross platform? I apologize if I abuse your patience.

[TRon]

Unfortunately I can't provide a 100% guarantee answer to that question.

In theory jamie's solution it is cross-platform. Unfortunately, as mostly in such cases, there is a but. It depends whether or not the underlying widgetset supports it (and if support for it has been implemented). See also widgetset and detailed roadmap information .

I do not have hands on experience with each and every widgetset to be able to provide a more/better informed answer.

ps: perhaps not applicable to your current question but also note "Lazarus known issues (things that will never be fixed)" and in case you are interested in the internals of LCL then have a look here (at the bottom of that page you find links to each individual interface which in itself link to other articles/pages that tell more about how things like messages, events etc work for a certain interface. It is a lot to digest though).