How to tell if running in console or winexe mode?

  • Thread starter Thread starter D H
  • Start date Start date
D

D H

Is there anyway to tell from within your code, either at compile-time or
run-time your assembly is running as a console app (exe) or windows gui
app (winexe)?

I wanted to for example create simple beep() and msgbox() functions that
work differently in either mode.
 
The question you're asking seems to indicate that you're doing
something peculiar. Console Apps and Windows Apps are fundamentally
different animals. You'd be much better factoring out all common code
into a library, then having a seperate console app and Windows app that
uses the common code.

Does that sound reasonable?

Regards,

Tim Haughton
 
Using VB and framework 1.1,
Dim b As Boolean = System.Windows.Forms.Application.MessageLoop
b is true if a message pump is running on the current thread, and false if
not. This gives you a runtime test.

In VB, you can start a message loop via Application.Run. Before Run,
MessageLoop returns false, while the main form runs it returns true, and
during termination, it returns false. The moral is that you shouldn't cache
this boolean.
 
Tim said:
The question you're asking seems to indicate that you're doing
something peculiar.
Click to expand...

As I explained, I used an incredibly simple example - make a beep()
function. One that works at all times. Regardless of winexe or exe.
I don't see anything "peculiar" or unreasonable about asking if
something so basic and simple is possible. (and if it's not, just say
so, don't tell me I must be doing something wrong or peculiar for even
asking).

I found an alternative in this one specific case is to call
microsoft.visualbasic.interaction.beep() which works on Mono and .NET
and in console or winexe apps. Of course that's not a very
generalizable solution for other cases, is it?

Console Apps and Windows Apps are fundamentally
different animals. You'd be much better factoring out all common code
into a library, then having a seperate console app and Windows app that
uses the common code.
Click to expand...

It's a beep. It couldn't be more simple. There is no common code.
What's uncommon about a beep?
 
D H said:
As I explained, I used an incredibly simple example - make a beep()
function. One that works at all times. Regardless of winexe or exe.
I don't see anything "peculiar" or unreasonable about asking if something
so basic and simple is possible.
Click to expand...

I think what Tim was trying to get across is that generally, if you are
targetting both Console and WinForms, you have two separate codebases
handling the presentation tier, and then you business and data tiers behind
them. Therefore, each codebase would only require the code it needs. The
console application would not use MessageBoxes, and the WinForms exe would
not use console I/O. Thus, the "something peculiar" you're doing is
approaching this from the wrong side. Rather than try to create a cross-UI
system library, it is far easier to simply have 2 presentation layers. Many
things in Windows UI do not cross well as concepts into Console UI and vice
versa. So the approach is "peculiar", not this specific instance (beep).
(and if it's not, just say so, don't tell me I must be doing something
wrong or peculiar for even asking).
Click to expand...

He didn't say that, he said that you're doing something peculiar for trying
to have a single codebase crossing Console and Winforms. I don't understand
how you get from his first sentence above to an attack on you for asking
your question?
I found an alternative in this one specific case is to call
microsoft.visualbasic.interaction.beep() which works on Mono and .NET and
in console or winexe apps. Of course that's not a very generalizable
solution for other cases, is it?
Click to expand...

No, it's not.
Console Apps and Windows Apps are fundamentally

It's a beep. It couldn't be more simple. There is no common code. What's
uncommon about a beep?
Click to expand...

Um, you actually said "Of course that's not a very generalizable solution
for other cases, is it?". This implies that you're looking at something more
extensive than a beep. You've already pointed out that you have a solution
for beep, and now Tim is quite delicately pointing out that your overall
approach is flawed, not the beep solution.
 
Back
Top