i googled for a problem with a lazarus app running on linux: no Hourglass cursor showing!

do i really need allways
screen.cursor := crHouglass;
followed by
Application.Processmessages;

Linux is:
infobash -v1
Host/Kernel/OS "siduxhome" running Linux 2.6.38-2.slh.7-aptosid-686 i686 [ sidux 2007-01 - ???? (200702210759) ]
CPU Info 2x Intel Core2 Duo E8500 @ clocked at [ 3335.000 MHz ] Videocard nVidia G92 [GeForce 8800 GT] X.Org 1.9.5 [ ] Processes 151 | Uptime 41min | Memory 609.2/3293.8MB | HDD Size 1250GB (19%used) | GLX Renderer GeForce 8800 GT/PCI/SSE2 | GLX Version 3.3.0 NVIDIA 270.30 | Client Shell | Infobash v3.35

John,

do i really need allways screen.cursor := crHouglass;

Yes, your program is responsible for indicating that you have started [or finished] a long process.

DSK wrote

Yes, your program is responsible for indicating that you have started [or finished] a long process.

Ok, but my problem is different:

in the app running on windows Hourglass is shown by:
screen.cursor := crHourglass;
but for  linux you need:
screen.cursor := crHourglass;
Application.ProcessMessages;

isn't that in conflict to:
"write once, compile anywhere" ?

Not really, because the LCL is a event based/driven GUI engine. You must leave the main thread enough processing time. When processing a long operation you must call
Application.ProcessMessages or put the operation into another queue. Otherwise your application stops responding.
The LCL is not a winapi emulator.

Mattias

Thanks for that explanation, changed my code templates :-))

just an idea:

i have to change that code templates on different computers.

What about an lazarus that can synchronize those user settings like chrome/firefox can do with links?

Would be a nice feature?!

John,

but for linux you need: screen.cursor := crHourglass; Application.ProcessMessages;

the Application.ProcessMessages; line helps on Windows as well and [now that I check] is in the WaitCursor unit that I generally use ... sorry I trimmed it in the quote.

Hello,
I'm translating the FPC messages file in italian. I'm done, but when testing my new file I discovered that Lazarus reports more or less errors in a source file according to the FPC message file used! O___O Wtf?

Explanation....

I was going to test my new messages file on my Lazarus. So I loaded a little project, put in a couple of errors just to give FPC something to complain, and build.
With standard message file I got:
Error 1
Error 2
Error 3
"fatal, compilation aborted".

Good. Next I put in my file, compile and got no errors, just "fatal, compilation aborted".

I reviewed my file thinking it was wrong (well, some mistakes there were), then tried some other one in the msg dir. Many MSG files behaves like mine (no errors, just the fatal) but using the russian language file, Lazarus reports:
Hint 1 (unreadable cyrillic txt)
Hint 2 (unreadable cyrillic txt)
Hint 3 (unreadable cyrillic txt)
Hint 4 (unreadable cyrillic txt)
Hint 5 (unreadable cyrillic txt)
Hint 6 (unreadable cyrillic txt)
Error 1 (unreadable cyrillic txt)
Fatal

What is happening here? Shouldn't I get the same error messages no matter what message file I use? (I checked my msg file for the error messages reported originally: there they were, perfectly translated).

Second issue, in the IDE Options dialog, Lazarus has the option for message file specification but it has no effect: I must specify the message file in fpc.cfg or else I keep getting english messages. It's a bug of Lazarus?
It's a bug of FPC?

Thanks

Massimo Soricetti wrote

Hello, I'm translating the FPC messages file in italian. I'm done, but when testing my new file I discovered that Lazarus reports more or less errors in a source file according to the FPC message file used! O___O

I posted too soon.
A short investigation discovered that Lazarus messages window filters out any message not starting with the words "Fatal", "Warning", "Error", "Note" or "Hint" (in English) :-|

P.S. at least my .msg file is OK...

John,

do i really need allways screen.cursor := crHouglass; followed by Application.Processmessages;

I have this bit of code I wanted to send but I wasn't going to post it without testing it [I've only ever run it on windows apps] on a Linux platform and I had some difficulties getting Lazarus on Ubuntu running - but that's another story. It's a bit of code I found ages ago and have refactored here and there. It makes dealing with changing to the HourGlass and back in any method much simpler to deal with ... at any rate here it is:

*****************************************************
unit CursorCtrl;
interface
uses
   Controls, Forms;
type
   ITemporaryCursor = interface
   ['{38BDD5A3-2E23-47D1-BD5D-54C49DBC95C3}']
     procedure Show;
   end;
   TTemporaryCursor = class(TInterfacedObject, ITemporaryCursor)
   private
     FOldCursor: TCursor;
     FNewCursor: TCursor;
   public
     constructor Create(const Cursor: TCursor = crHourglass);
     destructor Destroy; override;
     procedure Show;
   end;
function DisplayCursor(const Cursor: TCursor): ITemporaryCursor;
function DisplayHourglass: ITemporaryCursor;
implementation
{ TTemporaryCursor }
constructor TTemporaryCursor.Create(const Cursor: TCursor = crHourglass);
begin
   inherited Create();
   FOldCursor := Screen.Cursor;
   FNewCursor := Cursor;
end;
destructor TTemporaryCursor.Destroy;
begin
   Screen.Cursor := FOldCursor;
   inherited;
end;
procedure TTemporaryCursor.Show;
begin
   Screen.Cursor := FNewCursor;
   Application.ProcessMessages;
end;

{Use these routines to change a cursor before a long process in any method.}

function DisplayCursor(const Cursor: TCursor): ITemporaryCursor;
begin
   Result := TTemporaryCursor.Create(Cursor) as ITemporaryCursor;
   Result.Show;
end;

{- or -}

function DisplayHourglass: ITemporaryCursor;
begin
   Result := TTemporaryCursor.Create as ITemporaryCursor;
   Result.Show;
end;
end.

********************************************************************* To use it, add the unit to the implementation uses clause and then just call DisplayHourglass before any long process. It'll switch back to whatever the cursor was then the method terminates.

Hope you find it of interest.

DSK wrote

To use it, add the unit to the implementation uses clause and then just call DisplayHourglass before any long process. It'll switch back to whatever the cursor was then the method terminates.

Unless you store a reference of the result of the DisplayCursor() call, it will not work under FPC (like it does under Delphi). FPC is *not* compatible with the way Delphi works in this regard. The FPC developers are also not willing to fix this because the freeing of a undeclared interface reference in a local method is a undefined/undocumented feature of Delphi - even though thousands of Delphi developers have used that feature for many years.

NOTE:
The issue is only if you call DisplayCursor() without storing the result in a local variable.

Regards,
- Graeme -

2011/4/19 Graeme Geldenhuys :

I thought it was freed just like Delphi (so no resource leak), but not at the same time (which is undocumented) as Delphi. .

Vincent

Vincent Snijders wrote

I thought it was freed just like Delphi (so no resource leak), but not at the same time (which is undocumented) as Delphi.

That's exactly the issue I am referring too. Under Delphi the temporary interface reference gets freed only when the interface goes out of scope
- example when a procedure/function block ends. FPC I believe frees the temporary interface reference immediately (or something undefined - I can't remember).

Even though the "freeing of a temporary interface" is not documented in Delphi per se, its behaviour has been consistent for over a decade. There are even 3rd party products based on that behaviour (Raize CodeSite extensions etc). So even though it is not documented, it's behaviour is well known, understood and has always been consistent, no matter which version of Delphi you use.

But yes, I understand the FPC developers point of view too.

Regards,
- Graeme -

Graeme Geldenhuys wrote

NOTE: The issue is only if you call DisplayCursor() without storing the result in a local variable.

Good lord. That's a very interesting "gotcha". I'm very appreciative that you've caught this.

It seemed to work fine in the trivial example that I used to test it but then, it would seem that I didn't test it very well now did I. After putting a break-point in the Destroy event [after wasting 3 hours of my live trying find out how to write to the messages window - and failing] it does stop there right after the object is created.

It would seem then that the only option is to create a variable where- ever you want to change the cursor for the extent of the method it is declared in ... bummer.

Thanks,
Dave

PS, I'm using the git repository that you maintain - HUGE thanks for this.

Graeme Geldenhuys wrote

FPC I believe frees the temporary interface reference immediately (or something undefined - I can't remember).

This is exactly what I see happening in the testing I've just done.

Plop a;
Application.ProcessMessages;
in Destroy right after changing the cursor back to what was stored as FOldCursor and it "appears" that the cursor does not Dave

Graeme Geldenhuys wrote

The issue is only if you call DisplayCursor()

Actually, just for the record, it is the same for DisplayHourglass as well.

DSK wrote

Good lord. ?That's a very interesting "gotcha". I'm very appreciative that you've caught this.

I caught it by trying to create an alternative debugger to gdb, but using the same trick as the cursor cursor code shown here. Unfortunately the FPC implementation cannot work like under Delphi. And creating instance variables all over the place is a real pain. :-(

PS, I'm using the git repository that you maintain - HUGE thanks for this.

My pleasure.