[Estimated Reading Time: < 1 minute]
Because System.IsConsole is hardwired to TRUE on MAC OS:
{$IFDEF MACOS}
FileAccessRights := S_IRUSR or S_IWUSR or S_IRGRP or S_IWGRP or S_IROTH or S_IWOTH;
Test8086 := 2;
IsConsole := True;
// FindResourceCache.ModuleHandle := LongWord(-1);
{$ENDIF MACOS}
This is actually also the case for $ifdef LINUX, but nobody is likely to notice that, at least not just yet. 🙂
But it caused me no end of confusion when my FireMonkey app behaved one way on Windows and a completely different way on OSX.
Is there a rational explanation for this hard-wiring ?
AFAIK, on OS X (and Linux and other *nixes) every app is in fact a “console app”. ISTM there is always a console to write to (e.g. to log errors).
With respect I don’t think that is what “IsConsole” is supposed to mean, if it was then it would be called “HasConsole”.
Intuitively (and more importantly, according to the documentation!!) IsConsole is supposed to reflect whether the application was compiled with $APPTYPE CONSOLE or not. With IsConsole *not* acting to provide this information there is, as far as I can tell, no way to determine this by any other means, and being able to do that is important for my needs.
Aha!
The documentation now also states: “This directive is used in Delphi Windows programming only”
But I see no need for this restriction/limitation/excuse for the non-functioning of the IsConsole indicator variable. In fact, if anything the fact that a console is always available on OSX/Linux makes it all the more important to have some way of distinguishing between compiling an app expected to have/present a GUI and one that does not.
The fact that $APPTYPE CONSOLE is not strictly required in order to obtain a console on OSX/Linux is not a valid reason (imho) for the IsConsole indicator to become meaningless.
Since the people that write this stuff are not idiots perhaps you should be trying to understand the reasoning behind the decision before announcing that it is wrong.
David, your comment has a tone that I take exception to.
I did not announce that the “reasoning for the decision” was wrong. I merely point out the observed facts (and indeed asked if there was an explanation for this implementation decision).
Rudy offered just an explanation and it was that explanation with which I have some points of disagreement with the reasoning (as a rational basis for the behaviour). And you will note that explanation did not come from “the people who write this stuff” but was offered as _speculation_ as to the reason for the behaviour. Neither did I at any point suggest that anyone was an idiot (although I am coming very close to reaching just such a point right now ;)).
Before you come commenting in my blog and accusing me of doing things I didn’t do and having an attitude I don’t have, do me the courtesy of getting your facts straight first.
In the meantime, if you have something constructive to offer, perhaps your explanation as to why System variable designed not to indicate the presence of a console but to reflect the state of a compiler directive (this is the *documented* behaviour – to reflect the state of a compilation directive), does not actually do that on some platforms, then I am all ears.
Bear in mind that even on the *supported* Windows platform, IsConsole will be FALSE for an APPTYPE GUI application, even if the application has contrived to arrange a console for itself, which it is perfectly capable of doing if it wishes. IsConsole therefore is not – even if it was meant to be (which the documentation does not state that it is) – indicative of the mere presence of *a* console.
And lest we forget, there is a certain amount of evidence that at least _some_ of the people that do “write this stuff” are – if not idiots – then certainly prone to occasional mistakes in implementation and thinking.
Just like the rest of us. 🙂
I don’t have an explanation. Only the dev team could truly answer that. Why don’t you e-mail one of your friends there and ask?
Ah, so in the absence of any considered explanation yourself you simply chose to attack my choice to share my observations and considered opinion ? How very constructive. Thanks for the contribution.
Probably you missed a whole package structure of application (http://osxgnu.org/info/osxpackages.html). When you will have your app constructed this way then your app will be started as a typical MacOS application.
If MacOS just executable then OSX will treat is as “console”
Tokem, the problem isn’t “How do I make my OSX app behave as a console app” it is “How does my code know that it is being compiled in an app that is expected to behave like a console app”.
In Windows the two issues are conflated – the stub code emitted by the compiler has to be different for a CONSOLE app vs a GUI app. The System.IsConsole variable then tells code at runtime what the developer stated was the intent of the application, as expressed in the compiler directive (which also resulted in different stub code).
There may be no such difference in the stub code on OSX/Linux, making that function of the compiler directive redundant, but it still may be important for the code in that application to know the behaviour it is intended to display, most especially in library/framework code that may be used in either a GUI or a CONSOLE app.
Jolyon,
Catch your point. I was just confused when I did my first Delphi app for OSX that, upon lstarting, open terminal and does not show menu, so I belived that is also your case.
On OSX all apps are console (as Rudy mentioned).
Too bad. I have lots of code that does: if (IsConsole) then … else …; I’ll have to refactor that for Mac so my GUI apps behave correctly.
“How does my code know
that it is being compiled in an app that is expected to behave like a console app”
Use a conditional that you set in your project settings. Since there’s no need for it on a *nix system, you need to do it yourself.