Recent

Author Topic: Strange Delay() behavior  (Read 5412 times)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: Strange Delay() behavior
« Reply #15 on: November 14, 2018, 09:15:33 pm »
Quote
I don't understand your problem btw...
He (Thaddy) is generally grumpy (apparently), and regular subject to the moderators attention.

Edited some of his posts / removed others.

----
And for info "hero" and other such states are simply based on post count, not on quality or any other measure.
« Last Edit: November 14, 2018, 09:46:05 pm by Martin_fr »

SnoopyDog

  • New Member
  • *
  • Posts: 26
Re: Strange Delay() behavior
« Reply #16 on: November 15, 2018, 01:03:42 am »
Ok, sorry, next time I'll wait at least for one hour with my answer to calm down a bit   ;)

Thaddy

  • Hero Member
  • *****
  • Posts: 14204
  • Probably until I exterminate Putin.
Re: Strange Delay() behavior
« Reply #17 on: November 15, 2018, 07:46:28 am »
You'd better Sleep() over it.... 8-)
Specialize a type, not a var.

nfol

  • New Member
  • *
  • Posts: 17
Re: Strange Delay() behavior
« Reply #18 on: November 15, 2018, 01:05:15 pm »
First: No matter where the problem arises, I am happy to learn, that it is not inside my skull; I was going crazy.

Also I learned something about Windows. (I am new to FP, but used Turbo Pascal on DOS machines many years ago. That was more simple.)

I removed CRT and changed Delay() to Sleep(). That gave same behavior as with CRT and Delay().

With Application.ProcessMessages and Sleep(), the procedure works as intended.

I also tried the wait procedure put forward by GetMem. That works too and will be usefull when several delays are needed around in the application.

Thank you to you all!

Best regards,
Niels

 


PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Strange Delay() behavior
« Reply #19 on: November 15, 2018, 01:33:55 pm »
Aside: this can possibly be fixed/prevented:
Question for a Lazarus expert: is there anywhere in the Lazarus libraries (and fpGUI and MSEGui for that matter) a flag or unique variable that indicates a GUI application?
Then I can prepare a patch for the crt unit on the FPC side that tries to see if that is declared (similar to heapmm detection, with {$IF DECLARED(LAZGUI)}{$WARNING You can't use crt in a GUI application}{$ENDIF}). Maybe I can check if there is a console handle, but that maybe platform
No, this won't work as the FPC distribution is precompiled (this includes the CRT unit) and thus you can't add anything like that.

Thaddy

  • Hero Member
  • *****
  • Posts: 14204
  • Probably until I exterminate Putin.
Re: Strange Delay() behavior
« Reply #20 on: November 15, 2018, 01:54:32 pm »
Do you mean the crt unit is used by the compiler, Sven? If so you are right, if not I am right.
See hwo to resolve the heapmm issue: that's what I propose.
I do not know - apart from fp.exe - that the compiler itself uses crt. If so I am wrong indeed.

Anyway OP should use Sleep()
Specialize a type, not a var.

Thaddy

  • Hero Member
  • *****
  • Posts: 14204
  • Probably until I exterminate Putin.
Re: Strange Delay() behavior
« Reply #21 on: November 15, 2018, 03:07:49 pm »
I removed CRT and changed Delay() to Sleep(). That gave same behavior as with CRT and Delay().

With Application.ProcessMessages and Sleep(), the procedure works as intended.
Ok Niels, glad you picked up my suggestions (and some others that put you in the right direction except for crt  < those people who discussed that are beyond >:D) .
Nice to see it works now. O:-) 8-) ::) :D
Specialize a type, not a var.

SnoopyDog

  • New Member
  • *
  • Posts: 26
Re: Strange Delay() behavior
« Reply #22 on: November 15, 2018, 03:19:33 pm »
OMG  ::)

 

TinyPortal © 2005-2018