Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
console only OR screen only
#1
I'm building a small console utility.
If a parameter is given, the utility should run in the console and print the result there.
But if no parameter is given, a screen interface should be shown where user can enter parameter(s) and play with result.

This basically means, I want console:only when command$<>"" ELSE Screen:only

Code: (Select All)
$Console
If Command$ <> "" Then
  _ScreenHide
  _Console On
  _Dest _Console
Else
  _Console Off
  _ScreenShow
  _Dest 0
End If
Print "this is it"

If I run this program a very brief flickering can be observed in both cases:
- when doubleclick the exe, I see briefly a console window before the screen is shown and console window disappears
- when at commandprompt including parameter, a screen briefly comes up and disappears. (brief window focus change)

Anyone a good idea/approach to have 1 and only one of them from the very first beginning?
45y and 2M lines of MBASIC>BASICA>QBASIC>QBX>QB64 experience
Reply
#2
@mdijkens it's possible to improve the situation but unfortunately Windows makes it impossible to get exactly what you want.

The way to improve your application is to use `$ScreenHide`, this will stop the program from creating the graphics window at start-up (it will be delayed until the first `_ScreenShow`) and prevent the window from popping-up when run from a console. If you run that application with no parameters though (Ex. double-chick) it will still create a console window briefly like you're seeing. That issue is caused by the `$Console` line, but you can't remove it since you want your application to work correctly from the console.

The underlying issue is that Windows classifies applications as either a console application or a GUI application. When you use `$Console` you're declaring that your application is a console application, which means:

1. Your application always gets a console, if not started from an existing console one is created.
2. When started from an existing console, that console will wait for your program to exit before continuing on (and output from your program will go to that console).

That last one is the big issue and why you don't want your application to be GUI application. When you start a GUI application from an existing console, the console immediately returns to the prompt and doesn't wait for the GUI program to end, so you can't realistically output anything. You can see this if you open `cmd` or `powershell` and run `notepad`, that's a GUI application so the console doesn't wait for `notepad `to exit before showing the prompt again.

What you might consider is skipping the graphics window entirely and make it a console-only application. You should be able to use `Input` from the console to read your parameters, that might be good enough for your use-case.
Reply
#3
Thanks for the excellent explanation.

adding $ScreenHide does help not showing the screen when in console
when starting with double-click, first the console will be there briefly, but as I understand that is inevitable with $console applications.

The fact that with no params the console immediately returns when screen is starting is NOT an issue for me; once the user gets in the screen, he will stay there and do everything interactive (using mouse & graphics to set parameters)

So I guess (with $screenhide) I have the best possible and live with the brief flicker when starting in interactive mode...

Thanks!
45y and 2M lines of MBASIC>BASICA>QBASIC>QBX>QB64 experience
Reply




Users browsing this thread: 3 Guest(s)