Hi,

In the LCL-xxx widgetset roadmap [http://wiki.freepascal.org/Roadmap], there are some items under "lcl-fpgui" listed as "Partially Implemented". eg: TButton

How or where do I find out what is not working or completed?

Also, how do you test that a widget / component is 100% "working"? Is there some test app or test suite for this?

Regards,
- Graeme -

Graeme Geldenhuys wrote

How or where do I find out what is not working or completed?

There are various possibilities:

1> Check the bug tracker. But not many people report issues for LCL-fpgui, so I doubt it will help. This is useful for gtk2 for example.

2> Ask the maintainer, but there is none so this one also doesn't help. I wrote some parts of this, but in my last attempt to work on it LCL-fpgui wouldn't compile because something changed in fpgui

3> Test yourself, I guess that's the only solution

Also, how do you test that a widget / component is 100% "working"? Is there some test app or test suite for this?

Yes, see lazarus/examples/combobox.lpi for example

Hello Lazarus-List,

Tuesday, August 23, 2011, 12:56:54 PM, you wrote:

GG> In the LCL-xxx widgetset roadmap
GG> [http://wiki.freepascal.org/Roadmap],
GG> there are some items under "lcl-fpgui" listed as "Partially GG> Implemented". eg: TButton
GG> How or where do I find out what is not working or completed?

Standard tab components should be almost complete, or at least usable, but as nobody is using the widgetset it is quite difficult to determine if it is "complete".

GG> Also, how do you test that a widget / component is 100% "working"? Is GG> there some test app or test suite for this?

No test suite, I simply wrote a form with different objects and handle different events (most important ones) and check manually that they works, but event chain order, or operations inside an event could be not work as expected. I had not seen any serious missing in the standard tab components (except frame and action list which I do not know how to test).

There are some missings in the WinAPI compatibility layer like focus rect (missing xor effect).

TLabel can have serious problems due the WinAPI compatibility.

For sure there are some missing things not tested, like accelerators and others.

The examples folder can be used as a test suite.

Graeme Geldenhuys wrote

[http://wiki.freepascal.org/Roadmap],

Would anybody mind me adding TApplication.QueuAsyncCall, TThread.Synchronize, and PostMessage to the "Status of native controls on each widgetset" list ?

-Michael

Michael Schnell wrote

Would anybody mind me adding TApplication.QueuAsyncCall, TThread.Synchronize, and PostMessage to the "Status of native controls on each widgetset" list ?

Please add to "Status of features on each widgetset"

And please also create test projects for those and send to the bug tracker. I think it would be good to start linking each item in those tables to a test project in the lazarus source tree

Felipe Monteiro de Carvalho wrote

Please add to "Status of features on each widgetset"

OK, I'll try to do this tomorrow.

And please also create test projects for those and send to the bug tracker. I think it would be good to start linking each item in those tables to a test project in the lazarus source tree

I do have this test project. It should be usable for all widget types, but I only tried it with GTK, GTK2 and fpGUI. I failed to compile it (or any other application) for QT.

-Michael

None of those are widgetset features, since they are non visual.

Marco van de Voort wrote

None of those are widgetset features, since they are non visual.

All of them are implemented in the LCL via widgetset-interfaces, just like TButton.

Plus, the LCL also implements file access routines too (also non-visual), because the RTL has no UTF-8 support.

Strange, I always thought tthreads was in classes, with the primary checksynchronize in sysutils?

Plus, the LCL also implements file access routines too (also non-visual), because the RTL has no UTF-8 support.

By design.

Marco van de Voort wrote

Strange, I always thought tthreads was in classes, with the primary checksynchronize in sysutils?

I was talking mostly about PostMessage and QueueAsync. I had a vague memory about Synchronize requiring something from lcl-interfaces, but now I did a search here and it seams that the only thing that lcl-interfaces need to do for it is to call CheckSynchronize inside the loop of TSomethingWidgetSet.AppProcessMessages

So it seams that Synchronize might be off that list.

Marco van de Voort wrote

None of those are widgetset features, since they are non visual.

It would be great if they were not. But in fact regarding the way they are (or maybe even need to be) implemented, they are.

(btw.: TTimer is not visual as well and it is in this list, while TDataSource can be "visually placed on a Form" and has nothing to do with a GUI whatsoever and thus is not included.)

This is why in the Lazarus IDE "Build Mode" the alternatives denoted are called "Widget Type"s and in the source code it is named more appropriate with the unfortunately rather ambiguous term "Interface". I feel it would better to use "Widget Type" in the Wiki as well to improve the correspondence to the IDE.

-Michael

Marco van de Voort wrote

Strange, I always thought tthreads was in classes, with the primary checksynchronize in sysutils?

Yep, but "TThread.Synchronize" interfaces to the Widget Type (aka "Interface") code that is used by "TApplication" and when compiling selected according to the setting of the "LCLWidgetType" setting.

The other functions directly are part of this code.

-Michael

As TThread.Synchronize feeds the Event Queue that responsible for scheduling tasks for the main thread, it obviously is implemented depending on the setting of the "LCLWidgetType" setting, the value of which is the horizontal header if the table.

(BTW AFAIK, quite recently TThread.Synchronize did not work with fpGUI, while it did work w.g. with Win32, but Graeme did make it working by improving his WidgetType implementation.)

-Michael

I originally also put queueasync on that RTL list, but I now see where I got confused.

QueueAsync is a Lazarus call. The Delphi 2006+ call for it is .queue, but that is still unimplemented in FPC. .queue is more or less a synchronize that doesn't wait.

I had a vague memory about Synchronize requiring something from lcl-interfaces, but now I did a search here and it seams that the only thing that lcl-interfaces need to do for it is to call CheckSynchronize inside the loop of TSomethingWidgetSet.AppProcessMessages

It could be that it was, originally. But it is like this since at least 2.0.4

It is also possible to hook checksynchronize iirc, maybe Lazarus does that, and you have that in mind.

Where? The synchronize queue is in sysutils.

The other functions directly are part of this code.

Please explain.

Marco van de Voort wrote

QueueAsync is a Lazarus call. The Delphi 2006+ call for it is .queue, but that is still unimplemented in FPC.

In fact Delphi implements TThread.Queue. while Lazarus/FPC currently don't.

The LCL provides Application.QueueAsyncCall.

Both procedures are supposed to perform the same action. But

(1) Application.QueueAsyncCall is not a TThread class Function and thus does not need support from the RTL (thus the FPC team) and (2) Application.QueueAsyncCall is is more versatile, as it additionally to the Procedure itself and the self pointer, it also provides a parameter (pointer) to the procedure to be executed by the main thread.

-Michael

Marco van de Voort wrote

Where? The synchronize queue is in sysutils.

The events created by GUI actions and those created by TZThread.Synchronize and those created by PostMessage and aimed to "procedure...message" finally create actions calling the "Dispatch" mechanism. The current implementation obviously is that several parallel event queues are done for this. Obviously the main thread needs to wait until one of those queues changes from empty to not-empty. This "wait for multiple objects" needs to be implemented "somewhere". I understand that this is done in the "WidgetType"/"Interface" code that is compiled depending on the "LCLWidgetType" setting. Unfortunately this code is too complex to allow for quickly searching (and trying to singlestep crashes the debugger)

Anyway each single "WidgetType" code needs at lease to provide a hook for the queue. And thus it might or might not work depending on the Widget Type. This is what I think should be denoted in the Wiki.

Please explain.

QueuAsyncCall is a class function of TApplication and TApplication uses a lot of the WidgetType depending code.

PostMessage with WidgetType Win32 just is an API call and with WigdgetTpe gtk2 performs something internally to the program and seems perfectly workable. With fpGUI it does not work. So it obviously depends on the WidgetType setting.

-Michael

Michael Schnell wrote

PostMessage with WidgetType Win32 just is an API call and with WigdgetTpe gtk2 performs something internally to the program and seems perfectly workable. With fpGUI it does not work. So it obviously depends on the WidgetType setting.

I would imagine in the case of LCL-fpGUI, it is simply not implemented. fpGUI itself does have fpgPostMessage() and fpgSendMessage() functions, that work fine for what they were designed for.

Unfortunately the LCL has no help regarding its PostMessage() function, so I have no clue what it is supposed to do in the context of the LCL.

Regards,
- Graeme -

Graeme Geldenhuys wrote

I would imagine in the case of LCL-fpGUI, it is simply not implemented. fpGUI itself does have fpgPostMessage() and fpgSendMessage() functions, that work fine for what they were designed for.

Pleas don't get me wrong ! I did not intend to nag on this. I just used LCL-fpGUI as an example here.

Unfortunately the LCL has no help regarding its PostMessage() function, so I have no clue what it is supposed to do in the context of the LCL.

Unfortunately, as you know, I got stuck when my trying to enhance the help on TApplication.QueuAsyncCall. Once I can do this, I'll see what help can be written on PostMessage. In fact in the LCL, PostMessage just queues a "Message" (a set of four integers) in the appropriate queue. On the other site there seems to be a hook between the "procedure... message" FPC language construct and the WidgetType event scheduler that allows for waking up the main thread and firing the user code attached to the appropriate "procedure... message" statement (supposedly somehow via Dispatch).

-Michael

Michael Schnell wrote

(supposedly somehow via Dispatch).

Maybe via SendMessage() that uses the same "Message" parameter and simply calls Dispatch.

-Michael

Michael Schnell wrote

Where to place the testing project ?

In the bug tracker

Currently the testing project has a GUI and needs manual interaction. Is it viable to do automatic regression tests ? How should same be done ?

Vincent worked on that, I don't remember anymore how the automatic test suite works.

BTW when starting a TTimer that does not do anything, (while in the IDE) the fpGUI flavor of the test projects makes the IDE hang.

While doing what? Running the project?

Felipe Monteiro de Carvalho wrote

And please also create test projects for those and send to the bug tracker.

Where to place the testing project ?

Currently the testing project has a GUI and needs manual interaction. Is it viable to do automatic regression tests ? How should same be done ?

BTW when starting a TTimer that does not do anything, (while in the IDE) the fpGUI flavor of the test projects makes the IDE hang.

Outside of the IDE I get: "An unexpected Error occurred: Window does not have a Handle"

-Michael

Michael Schnell wrote

BTW when starting a TTimer that does not do anything, (while in the IDE) the fpGUI flavor of the test projects makes the IDE hang.

I have no idea what you test project does, but here I use many timers for many things - again without issues.

I have recently rewritten the TfpgTimer code used under fpGUI+Windows. The old implementation was severely broken. So if you haven't recently gotten a fpGUI update, I would strongly recommend you do so.

I daily do fetch updates.

I seem to remember that some time ago, TTimer in my testing project worked.

I did some more tests:

In fact the IDE does not crash. It shows a hidden Message Window: "Project eventtestraises exception class 'RunRerror(201)'

The TTimer is just instantiated. I can reach a breakpoint at fpguiobject.inc line 151.

Stepping over same to line 153 shows a decent value for the Timer variable: $B761AA00.

But stepping line 153 produces the exception.Same is "Result :=
PtrInt(Timer); " This is a 32 Bit Linux aned PtrInt in fact is "LongInt".

So the Loingint will be negative and as THandle is PtrUInt which again is DWord, a range check exception is raised.

Changing the line to  " Result := THandle(Timer); "  makes the Timer work.

I don't know if this is appropriate for all Archs....

-Michael

Michael Schnell wrote

Changing the line to " Result := THandle(Timer); " makes the Timer work. I don't know if this is appropriate for all Archs....

Maybe post that question as a new message thread. This message thread has already diverged a bit, so such questions might go unnoticed in this thread. Alternative, generate a patch and submit it to Mantis.

I updated my testing project so that it now can more easily be integrated into a regression test. I separated the active code and the GUI into two different units.

Unfortunately I still did not find out how I can provide the code to the Lazarus source file pool.

-Michael

Attach it to a Mantis bug report, and include in project 'Patches'

Michael.

Attach it to a Mantis bug report, and include in project 'Patches'

Thanks,
Done.

-Michael

On 09/05/2011 05:28 PM, Michael Schnell wrote:I'd like to do an improvement to this project, but I got stuck.

I wanted to do it in a way that the active unit can unmodified be used to be integrated in some regression test to be run unmonitored.

One of the test cases I do is "procedure()...message". (e.g. to be fed by "dispatch()" )

Right now this is denoted in the main form and thus can't be done in the "active" unit.

Of course I don't want to do anything depreciated in the testing project and so I ask here about how to proceed.

I tried to create a TWinControl sibling and assign the main form as it's owner and it's Parent.

I do the "procedure()...message" for this object.

I hoped the dispatch mechanism would reach this procedure. But it does not. (I tested in Delphi: same there.)

So is there a valid way to define some object in a unit in a way that the "procedure()...message" is reached by the dispatch mechanism ?

(I don't dare to call Application.CreateForm a second time.)

-Michael