ShowFileDialog In Console
-
Hello, I try to add OpenFileDialog to my code and i can not. What to do? **I develop in console NOT in WindowsForm
Yes u can do his with System.Windows.Forms namesspace go through the below sample code
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows.Forms;namespace test
{
class Program
{
static void Main(string[] args)
{** OpenFileDialog ofd = new OpenFileDialog(); ofd.ShowDialog();** } }}
Rajesh B --> A Poor Workman Blames His Tools <--
-
Yes, well a console application is not supposed to have GUI, does it?
A console app starts its execution in a console, it may however turn itself into a regular WinForms app; there is nothing that prevents it from creating and showing Forms. The opposite is not possible: a WinForm app cannot perform input/output operations through the console if it were launched from a "DOS window" or a "Command Prompt" window (it can use a console, but that will not be the same as the launch window). The problem the OP is probably facing is there is no
using System.Windows.Forms;statement included automatically, so he should add that first if he wants to create Forms by code. The context menu "Add Windows Forms" however is available in the solution pane. :)Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
-
A console app starts its execution in a console, it may however turn itself into a regular WinForms app; there is nothing that prevents it from creating and showing Forms. The opposite is not possible: a WinForm app cannot perform input/output operations through the console if it were launched from a "DOS window" or a "Command Prompt" window (it can use a console, but that will not be the same as the launch window). The problem the OP is probably facing is there is no
using System.Windows.Forms;statement included automatically, so he should add that first if he wants to create Forms by code. The context menu "Add Windows Forms" however is available in the solution pane. :)Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
I know. But in this era, if you build a console app, you're planning to be non-interactive right? I mean you'll happily accept stdin, stdout, all the pipes in the world, and even if you want to build a service, you won't put up a dialog will you? I know even Microsoft does this (misuse of MessageBox, shutdown /I interface), but if you're writing console, you're writing console. I only use console if I plan to run on posix, or target server core, or do a quick test where I don't want be bothered by drawing forms). I think it's a base choice: either you'r scriptable, and you go for console, or you're point-n-click.
-
I know. But in this era, if you build a console app, you're planning to be non-interactive right? I mean you'll happily accept stdin, stdout, all the pipes in the world, and even if you want to build a service, you won't put up a dialog will you? I know even Microsoft does this (misuse of MessageBox, shutdown /I interface), but if you're writing console, you're writing console. I only use console if I plan to run on posix, or target server core, or do a quick test where I don't want be bothered by drawing forms). I think it's a base choice: either you'r scriptable, and you go for console, or you're point-n-click.
I disagree, there may be good reasons to create a hybrid. What I would like to do is write a single app (one EXE) that: - when no command line arguments are present, behaves like a WinForms app, i.e. it offers a GUI and the user can start setting options and clicking buttons; - when command line arguments are present, behaves like a Console app, i.e. perform its job, as defined by the command line arguments, and provide output to the console, so it can be embedded inside a batch file, its output could be redirected by the shell, etc. All this without a console nor a WinForm form popping up for a fraction of a second, to be hidden again when it is not wanted. Turns out Windows does not let one do that. There is a single bit in the EXE format (PEF) that says this app is a console, if not started from a console, open one; or it isn't, so don't give it access to its caller. Example: I like WinZip a lot; long ago it was a DOS utility, no GUI, just command line operation. Fine. Then it turned into a WinForm app, with a GUI. And then they fixed it, by adding a "command line extension", a second EXE to fix the lack of scriptability. So MS themselves need two EXE to do basically the same thing twice, with different user interfaces. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
-
I disagree, there may be good reasons to create a hybrid. What I would like to do is write a single app (one EXE) that: - when no command line arguments are present, behaves like a WinForms app, i.e. it offers a GUI and the user can start setting options and clicking buttons; - when command line arguments are present, behaves like a Console app, i.e. perform its job, as defined by the command line arguments, and provide output to the console, so it can be embedded inside a batch file, its output could be redirected by the shell, etc. All this without a console nor a WinForm form popping up for a fraction of a second, to be hidden again when it is not wanted. Turns out Windows does not let one do that. There is a single bit in the EXE format (PEF) that says this app is a console, if not started from a console, open one; or it isn't, so don't give it access to its caller. Example: I like WinZip a lot; long ago it was a DOS utility, no GUI, just command line operation. Fine. Then it turned into a WinForm app, with a GUI. And then they fixed it, by adding a "command line extension", a second EXE to fix the lack of scriptability. So MS themselves need two EXE to do basically the same thing twice, with different user interfaces. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
MS is moving more to a 'Unix/Linux like model'. Important system utilities, like diskpart, ipconfig, increasingly have no user interface. Even worse, most of these utilities are implemented twice: in the diskpart example, you have the diskpart.exe, which does some (more) things than the storage management in msc. But both rely on background or system services to do the job. The GUI is there for the casual user, who just wants to get the job done once, the console app is there for the sysadmin who wants something special, or needs scriptable deployment. There's always a tension between 'ease of use' and 'advanced functionality'. Some functionality cannot be expressed in GUI terms, but may be obvious to the sysadmin with some programming experience. That's always been my gripe with Unix/Linux systems: pulling up a man page gives me information on how to run the Large Hadron Collider, but I'd be buggered on how to delete a file with a space in the filename in my home directory. I suppose it's a choice, but I think supplying two utilities for the same job (one graphical for the casual user, one performing for the expert) is a good choice. Another philosophical discussion :-\
-
MS is moving more to a 'Unix/Linux like model'. Important system utilities, like diskpart, ipconfig, increasingly have no user interface. Even worse, most of these utilities are implemented twice: in the diskpart example, you have the diskpart.exe, which does some (more) things than the storage management in msc. But both rely on background or system services to do the job. The GUI is there for the casual user, who just wants to get the job done once, the console app is there for the sysadmin who wants something special, or needs scriptable deployment. There's always a tension between 'ease of use' and 'advanced functionality'. Some functionality cannot be expressed in GUI terms, but may be obvious to the sysadmin with some programming experience. That's always been my gripe with Unix/Linux systems: pulling up a man page gives me information on how to run the Large Hadron Collider, but I'd be buggered on how to delete a file with a space in the filename in my home directory. I suppose it's a choice, but I think supplying two utilities for the same job (one graphical for the casual user, one performing for the expert) is a good choice. Another philosophical discussion :-\
Michel Godfroid wrote:
I suppose it's a choice
At the very least, it is a choice I want to make myself; not have somebody else make for me. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
-
A console app starts its execution in a console, it may however turn itself into a regular WinForms app; there is nothing that prevents it from creating and showing Forms. The opposite is not possible: a WinForm app cannot perform input/output operations through the console if it were launched from a "DOS window" or a "Command Prompt" window (it can use a console, but that will not be the same as the launch window). The problem the OP is probably facing is there is no
using System.Windows.Forms;statement included automatically, so he should add that first if he wants to create Forms by code. The context menu "Add Windows Forms" however is available in the solution pane. :)Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
Hi Luc, not for you but for anyone viewing who may wish to know how...
Luc Pattyn wrote:
it can use a console
Dave
If this helped, please vote & accept answer!
Binging is like googling, it just feels dirtier. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) -
MS is moving more to a 'Unix/Linux like model'. Important system utilities, like diskpart, ipconfig, increasingly have no user interface. Even worse, most of these utilities are implemented twice: in the diskpart example, you have the diskpart.exe, which does some (more) things than the storage management in msc. But both rely on background or system services to do the job. The GUI is there for the casual user, who just wants to get the job done once, the console app is there for the sysadmin who wants something special, or needs scriptable deployment. There's always a tension between 'ease of use' and 'advanced functionality'. Some functionality cannot be expressed in GUI terms, but may be obvious to the sysadmin with some programming experience. That's always been my gripe with Unix/Linux systems: pulling up a man page gives me information on how to run the Large Hadron Collider, but I'd be buggered on how to delete a file with a space in the filename in my home directory. I suppose it's a choice, but I think supplying two utilities for the same job (one graphical for the casual user, one performing for the expert) is a good choice. Another philosophical discussion :-\
Michel Godfroid wrote:
gives me information on how to run the Large Hadron Collider, but I'd be buggered on how to delete a file with a space in the filename in my home directory
:laugh: Apple probably 'have an app for that' too!
Dave
If this helped, please vote & accept answer!
Binging is like googling, it just feels dirtier. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) -
Hi Luc, not for you but for anyone viewing who may wish to know how...
Luc Pattyn wrote:
it can use a console
Dave
If this helped, please vote & accept answer!
Binging is like googling, it just feels dirtier. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn):thumbsup:
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
-
Hello, I try to add OpenFileDialog to my code and i can not. What to do? **I develop in console NOT in WindowsForm
As others have mentioned, you need to add the line
using System.Windows.Forms;
to your code. I would also clarify you need to add a reference to the System.Windows.Forms assembly in your project (since this is not automatically included in a console project). Dybs
The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen