How to tell if running in console or winexe mode?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

D H - 17 Apr 2005 17:46 GMT

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.

Reply to this Message

Tim Haugton - 17 Apr 2005 20:09 GMT

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

Reply to this Message

D H - 18 Apr 2005 05:07 GMT

> The question you're asking seems to indicate that you're doing
> something peculiar.

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.

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

Reply to this Message

Sean Hederman - 18 Apr 2005 05:57 GMT

>> The question you're asking seems to indicate that you're doing
>> something peculiar.
[quoted text clipped - 3 lines]
> I don't see anything "peculiar" or unreasonable about asking if something
> so basic and simple is possible.

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).

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?

No, it's not.

> Console Apps and Windows Apps are fundamentally
>> different animals. You'd be much better factoring out all common code
[quoted text clipped - 3 lines]
> It's a beep. It couldn't be more simple. There is no common code. What's
> uncommon about a beep?

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.

Reply to this Message

AMercer - 18 Apr 2005 02:09 GMT

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.

> 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.

Reply to this Message

How to tell if running in console or winexe mode?

Free Magazines