C / C++ / MFC

10:29 13 Mar '10

Hi All,

I am trying to add a cmd functionality into my app, however it's not working very well and I am looking for alternate methods. What I'm going right now is taking an input command and using CreateProcess with cmd /C *command* > outputFile, then reading the file and displaying the output. However, the problem with this approach is that if I want to start an app, lets say Notepad, I would not be able to do anything else until Notepad closes. As well, the cd command is rendered useless, as when cmd exits and I call another command, the new cmd created by CreateProcess is still at the same directory.

Does anyone have any suggestions for a different approach - perhaps somehow piping the input/output from the cmd window directly to my app?

Thanks very much. Smile | :)

11:52 13 Mar '10

Oh, and I can't distinguish between a successful command and an unsuccessful one (whether that command even exists or not).
Sign In·View Thread·Permalink

Re: "Virtual" Command Prompt [modified]

Hristo Bojilov

12:39 13 Mar '10

Have you tried to create console for your process with AllocConsole? Life is a stage and we are all actors!
Sign In·View Thread·Permalink

13:31 13 Mar '10

No, I haven't because I don't see how would I receive the output of any command with that method. I don't see how I can input stuff into it either... EDIT: aha, I see now. Going to try it right now. Thanks! modified on Saturday, March 13, 2010 6:40 PM
Sign In·View Thread·Permalink

14:41 13 Mar '10

Okay, that doesn't work either because the only ways I can actually call the command is ShellExecute or system() - they both cannot change the current directory. I'm going to try ShellExecute instead now, I think that might work. Thanks again for your help.
Sign In·View Thread·Permalink

Modeless dialog closing when 'Enter' key is pressed?

Stephen Hewitt

19:23 13 Mar '10

Start the command directly but use pipes to redirect it's output. See this[^] article for details.

As for telling when the program is done use the process HANDLE returned in the LPPROCESS_INFORMATION structure passed to CreateProcess. A process HANDLE can be passed to one of wait functions such as WaitForSingleObject because it becomes signalled when the process has finished executing. Also note that a common mistake made by people is not to close the process and thread HANDLEs when they're done with them (or not at all).

Use GetExitCodeProcess to retrieve the return code.

Steve

Spawn@Melmac

9:05 13 Mar '10

Ok sorry for being dumb but I have been staring at this for a couple of days now and I am getting nowhere.

My dialog has a menu with a couple of controls, the main one being a CTreeCtrl.

I have captured the OnCancel() to prevent accidental closure but I notice that the 'Enter'/CR key causes the app to close and I have no idea why? It triggers an orderly close bypassing the OnCancel().

I know I have missed something but I just cannot see what.

Any pointers?

Many thanks

Alan

Re: Modeless dialog closing when 'Enter' key is pressed?

Spawn@Melmac

9:17 13 Mar '10

Please ignore this. Just figured out that I did not have a handler in place for the OnOK. Thus the default behaviour was being called which closes the app. Doh! Sorry for wasting your time guys. Alan
Sign In·View Thread·Permalink	5.00/5 (1 vote)

SOCKET_ERROR when calling send method from seperate class

Re: SOCKET_ERROR when calling send method from seperate class

7:49 13 Mar '10

Hi,

I have two classes, MainDlg.cpp, and Game.cpp . My MainDlg.cpp file is responsible for TCP communication, and it works fine on its own. I initially start MainDlg.cpp and then I start the Game.cpp class from there. Iam trying to call the DoSend() (on MainDlg.cpp) method from the Game.cpp file and it just results in a SOCKET_ERROR !

Just for experimentaion I've tried to call a method on MainDlg.cpp from Game.cpp to display a simple MessageBox and it works, so the problem is not with the class object I created.

This is how I created/call the Game.cpp object on MainDlg.cpp

Game* game = new Game;
game->Create(Game::IDD);

When the Game.cpp dialog comes up, this is how I execute the method on MainDlg.cpp:

CMainDlg* Main = new CMainDlg;
Main->GetResults();

In MainDlg.cpp :

GetResults method: <-- Works fine when run locally

void CMainDlg::GetResults()
{
	Message_PDU Message;
	Message.iMessageNumber = 80;
	DoSend(Message);
}

DoSend Method: <-- Works fine when run locally

void CMainDlg::DoSend(Message_PDU Message) // Send Message to Server
{	
	int iBytesSent;
	iBytesSent = send(m_iSocket, (char *) &Message, sizeof(Message_PDU), 0);
	if(SOCKET_ERROR == iBytesSent)
	{
		MessageBox("Failed to send","Client");
	}
}

Any help will be really appreciated!

^CPallini

7:56 13 Mar '10

Did your applications performed correctly the preliminary steps (i.e. there's an established connection between client and server?)?
Smile | :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]

Re: SOCKET_ERROR when calling send method from seperate class

Re: SOCKET_ERROR when calling send method from seperate class

8:08 13 Mar '10

Yes, the connection is started and is running. On the server side I have a small counter that counts the active connections, and before/after I start the Game.cpp dialog it remains connected... =/
Sign In·View Thread·Permalink

Re: SOCKET_ERROR when calling send method from seperate class

8:45 13 Mar '10

OK just for experimentation I tried to do a simple SetWindowText from the secondary class, and it resulted in a Debug Assertion error, when I debugged I got this:

void CWnd::SetWindowText(LPCTSTR lpszString)
{
	ENSURE(this);
	ENSURE(::IsWindow(m_hWnd) || (m_pCtrlSite != NULL));
 
	if (m_pCtrlSite == NULL)
		::SetWindowText(m_hWnd, lpszString);
	else
		m_pCtrlSite->SetWindowText(lpszString);
}

I think this problem has nothing to do with the sockets and has something to do with permissions?

Sorry I am new to C++

krmed

11:26 13 Mar '10

The problem is that when you do this:

CMainDlg* Main = new CMainDlg;Main->GetResults();

in your Game dialog, this creates a NEW INSTANCE of the main dialog - not the already existing one. This new one has not even done initialization of it's windows.

What you need to do is to make

CMainDlg* Main;

a member variable in your Game dialog, and then change the way you create the game dialog in the main dialog to:

Game* game = new Game;
game->Main = this;
game->Create(Game::IDD);

Now you'll find that Main (the member variable in your Game dialog actually points to the existing Main dialog.

Hope that helps.

Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193

Re: SOCKET_ERROR when calling send method from seperate class

12:01 13 Mar '10

it worked! Karl YOU ARE A STAR! Thank you so much!
Sign In·View Thread·Permalink

Window class, caption

trioum

5:26 13 Mar '10

Suppose there are multiple windows application opens. now I want to know the class and caption of all the open windows application . Trioum
Sign In·View Thread·Permalink

Eugen Podsypalnikov

5:34 13 Mar '10

It could be your start point[^] `virtual void BeHappy() = 0;`
Sign In·View Thread·Permalink

trioum

5:43 13 Mar '10

But How Can I get the class and Caption programmatically Trioum
Sign In·View Thread·Permalink

Eugen Podsypalnikov

13:58 13 Mar '10

For each iterated window you could use the `GetClassName(..)` and `GetWindowText(..)` functions `virtual void BeHappy() = 0;`
Sign In·View Thread·Permalink

DavidCrow

6:20 13 Mar '10

Have you tried `EnumWindows()`? "One man's wage rise is another man's price increase." - Harold Wilson "Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons "Man who follows car will be exhausted." - Confucius
Sign In·View Thread·Permalink