Recent

Author Topic: [SOLVED] Components with console applications  (Read 4553 times)

Kurt

  • Jr. Member
  • **
  • Posts: 59
[SOLVED] Components with console applications
« on: September 09, 2023, 06:30:10 pm »
Is there any way to use components with a console application the same way they are used with visual ones?  It would be nice to drop non-visual components on a container, and interact with them visually.  Or do I have to do everything programmatically?

I suppose I could have a visual form that I instantiate but never actually display, but I need to ensure I do this in a way that the resulting app has no gui library dependencies on Linux (it may run on small console-only installations).
« Last Edit: September 26, 2023, 03:05:37 am by Kurt »

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4442
  • I like bugs.
Re: Components with console applications
« Reply #1 on: September 09, 2023, 08:54:29 pm »
Use a DataModule instead of a form for the non-visual components.
Then set the widgetset of your LCL app to NoGUI.
For example LazBuild is a NoGUI app because it depends on LCL through so many units.
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

Kurt

  • Jr. Member
  • **
  • Posts: 59
Re: [SOLVED] Components with console applications
« Reply #2 on: September 10, 2023, 05:53:44 pm »
Perfect!  It's actually too perfect in that it introduces an issue with waiting, but It's a separate issue so I'll post about it in a new thread.

Kurt

  • Jr. Member
  • **
  • Posts: 59
Re: [UNSOLVED] Components with console applications
« Reply #3 on: September 10, 2023, 09:05:26 pm »
Back to unsolved.  I can't get this to work.  I set up the DataModule and its components, but ttimer events aren't firing, some Indy stuff works because it's multi-threading and has its own timings, but a lot doesn't.

It seems there is no message processing loop and I can't for the life of me figure out how to do one.  A console app with no widget set appears to have no message processing loop.  A console app derrives directly from TCustomApplication, so doesn't have TApplication.ProcessMessages.


Is what I want to do possible?
« Last Edit: September 10, 2023, 09:09:47 pm by Kurt »

KodeZwerg

  • Hero Member
  • *****
  • Posts: 1982
  • Fifty shades of code.
    • Delphi & FreePascal
Re: [UNSOLVED] Components with console applications
« Reply #4 on: September 11, 2023, 12:17:29 am »
To have a window message loop you need ...... a window .... tadaaadaaa  O:-)
« Last Edit: Tomorrow at 31:76:97 xm by KodeZwerg »

TRon

  • Hero Member
  • *****
  • Posts: 2200
Re: [UNSOLVED] Components with console applications
« Reply #5 on: September 11, 2023, 02:55:46 am »
Back to unsolved.  I can't get this to work.  I set up the DataModule and its components, but ttimer events aren't firing, some Indy stuff works because it's multi-threading and has its own timings, but a lot doesn't.
KodeZwerg explained that better than I ever could.

But... why would you want tot use timers in the first place. Such application that you speak about is event driven except not by using a standard windows message loop. You can create your own event loop and doing so in any which way is most convenient for you.

So as a simple example for a timer you could create your custom "timer" class with for example an update event that is called in your custom event loop and each and every time update is executed you check the time, check it against your interval property and either fire an event that is attached to your custom timer class or post a (event) message to your custom loop (which your event loop would have to deal with accordingly).

But for timed events I would probably just check against the current time and elapsed time in my custom event loop and when it matches, invoke the routine that needs to be run. It all depends on what you wish to achieve and how complicated you wish to make things. Another solution could be to use a thread instead.

Quote
Is what I want to do possible?
Sure, no problem. You just cant use any components that depend on the presence of a windows message loop (actually that is not entirely true because you could always resort to using a hidden window but in that case: what is the point).

PS: if you want to see a custom (terminal based) loop in action you can take f.e. a look at FreeVision
« Last Edit: September 11, 2023, 03:05:59 am by TRon »

Kurt

  • Jr. Member
  • **
  • Posts: 59
Re: [UNSOLVED] Components with console applications
« Reply #6 on: September 13, 2023, 10:39:50 pm »
To have a window message loop you need ...... a window .... tadaaadaaa  O:-)
Well, I wasn't asking for a window message loop.  I was inquiring about a message loop.

There is, as I've discovered, a very basic message handler in the nogui widget set.  It sorts out synchronization objects.  There is no reason why timer object support couldn't have been added to this paradigm.  I don't think it would even be that hard.  You don't need a widget set's window messaging system to support a timer.  You just need an OS, which I suspect all my apps users will have. ;)

Yes, I can easily use some other mechanism for my own timing needs.  I do it all the time in C.  That's not the problem.  My problem is that a bunch of non-visual components seem to themselves use TTimer to do things in the background or to handle their timeouts.  It's a little frustrating because you can't tell ahead of time which nonvisual component has problems unless you individually check the source for each one.  It would be nice if in the constructor for TTimer if it immediately tested the ability to actually time.  That would eliminate the guessing in about 90% of the cases of whether a non-visual component will work in nogui.

I still like the idea of using Lazarus for my project, I think in the end it will make what I'm doing easier.  Right now, looking at the code and the ORBAT of components I'm looking at using, it seems like the shortest path to do that is to implement TTimer support in the nogui widget handler.

alpine

  • Hero Member
  • *****
  • Posts: 1015
Re: [UNSOLVED] Components with console applications
« Reply #7 on: September 14, 2023, 01:50:32 pm »
@Kurt
It may be not new for you, but LCL resembles VCL from the early days, which in turn originally was for Windows. The GUI is inseparable part and the console is a kind of compatibility feature on top of it. TTimer is implemented by means of a widget set (i.e. messages, callbacks, etc.). Not to mention the early Windows apps got no big notion of threads and were just a big message loop handlers.
It is your decision if it's worth to artificially accommodate message loops in console just to have few properties into the designer or simply to reconsider not to use LCL components.
IMHO it doesn't. You can hit other curbs very soon.

Once I wrote a non visual component for protocol communication purposes. I had serious trouble using it in a daemon application, which also doesn't have 
a normal message loop. The problem was TThread.Synchronize mechanism, et al. but there was a workaround for that.
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

Kurt

  • Jr. Member
  • **
  • Posts: 59
Re: [UNSOLVED] Components with console applications
« Reply #8 on: September 16, 2023, 02:38:08 am »
or reconsider not to use LCL components.[/quote

Maybe.  But it's the access to the LCL components that makes Lazarus attractive for this project - or rather attractive enough to investigate.  If I can't use those, then Lazarus is a liability and I'll just do it handraulically with a traditional Unix-style select() loop. 

Quote
IMHO it doesn't. You can hit other curbs very soon.

That may be true.  So far, thread synchronization seems to be the one part of the traditional message handling subsystem that nogui supports.  So far the biggest limitation to using other LCL components that I've found is their liberal use of TTimer.  But there may be other gotchas I haven't found yet.

There seems to be a real missed opportunity.  Lazarus non-visual could have been what Go is today.  Of course, I'm sure everyone who finds Lazarus doesn't do what he wants it to do says it's a missed opportunity. ;)

Having admitted I'm aware of my own bias there, I still really wanna know who wrote noguiint.pp, got to writing CreateTimer() and said, "NOPE, can't fuckin' do that without GUI...  Result:=0 boyz".  Cuz I wanna raz that person just a bit. ;)

TRon

  • Hero Member
  • *****
  • Posts: 2200
Re: [UNSOLVED] Components with console applications
« Reply #9 on: September 16, 2023, 03:34:43 am »
or reconsider not to use LCL components.[/quote

Maybe.  But it's the access to the LCL components that makes Lazarus attractive for this project - or rather attractive enough to investigate.  If I can't use those, then Lazarus is a liability and I'll just do it handraulically with a traditional Unix-style select() loop. 

Quote
IMHO it doesn't. You can hit other curbs very soon.

That may be true.  So far, thread synchronization seems to be the one part of the traditional message handling subsystem that nogui supports.  So far the biggest limitation to using other LCL components that I've found is their liberal use of TTimer.  But there may be other gotchas I haven't found yet.

There seems to be a real missed opportunity.  Lazarus non-visual could have been what Go is today.  Of course, I'm sure everyone who finds Lazarus doesn't do what he wants it to do says it's a missed opportunity. ;)

Having admitted I'm aware of my own bias there, I still really wanna know who wrote noguiint.pp, got to writing CreateTimer() and said, "NOPE, can't fuckin' do that without GUI...  Result:=0 boyz".  Cuz I wanna raz that person just a bit. ;)
Too time consuming to figure out who/what was quoted but have you considered the fact that that is probably why there exist this ?

btw: also gitlab has something named history. You should definitely try it...
« Last Edit: September 16, 2023, 03:36:25 am by TRon »

jamie

  • Hero Member
  • *****
  • Posts: 6022
Re: [UNSOLVED] Components with console applications
« Reply #10 on: September 16, 2023, 03:57:10 am »
Maybe all that is needed is a windows app but using nothing more than a TApplication instance.

That gives you a message loop.

 You can at any time create a form at runtime to display things.
 
 A Timer may require to be sitting in a window, but that window does not need to be displayed.
The only true wisdom is knowing you know nothing

alpine

  • Hero Member
  • *****
  • Posts: 1015
Re: [UNSOLVED] Components with console applications
« Reply #11 on: September 16, 2023, 10:33:33 am »
Maybe all that is needed is a windows app but using nothing more than a TApplication instance.

That gives you a message loop.
Can you do that on a bare Linux with no GUI installed?
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4442
  • I like bugs.
Re: [UNSOLVED] Components with console applications
« Reply #12 on: September 19, 2023, 07:52:17 pm »
Having admitted I'm aware of my own bias there, I still really wanna know who wrote noguiint.pp, got to writing CreateTimer() and said, "NOPE, can't fuckin' do that without GUI...  Result:=0 boyz".  Cuz I wanna raz that person just a bit. ;)
I guess NoGUI widgetset was originally a hack to get LazBuild and maybe other programs to compile.
Adding TTimer support would still be a good idea. It would extend its usefulness.
I personally have tried to reduce dependencies and remove LCL dependency from LazBuild but it is super difficult.
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

zeljko

  • Hero Member
  • *****
  • Posts: 1582
    • http://wiki.lazarus.freepascal.org/User:Zeljan
Re: [UNSOLVED] Components with console applications
« Reply #13 on: September 19, 2023, 09:07:54 pm »
Check TFreeTimer from here https://www.theo.ch/Kylix. It was maded for Kylix, but just replace Libc with BaseUnix and Unix (and fix relevant code here and there, not big problem) and you can use TFreeTimer as timer in console apps.

TRon

  • Hero Member
  • *****
  • Posts: 2200
Re: [UNSOLVED] Components with console applications
« Reply #14 on: September 19, 2023, 10:35:34 pm »
Apparently you have to spell out things these days so there we go: TFPTimer does the (same) job *period*

 

TinyPortal © 2005-2018