C / C++ / MFC

1-Mar-06 6:00

I've got some executable which runs with its cygwin.dll under windows and was compiled under cygwin.
It accepts to its stdin strings and read them with fgets();
if(fgets() == NULL)
return; //that is ctrl+z was pressed

This works if we run it from windows.
But if we run it thru win app with createprocess() and puts strings thru pipe to it it recieves them correctly and now we want to stop its reading stdin and write to it \032\n that is ctrl+z but its fgets compiled with cygwin does not recognize it as stop writing to me and fgets should return 0, it reads it as \032\n string!!!
and waits for another string to be written.

VC++ compiled console executable with fgets() correctly understand \032\n as ctrl+z and we can terminate it from win app.

What's the EOF symbol for cygwin compiled fgets?

9ine

Dan McCormick1-Mar-06 7:32

Dan McCormick

1-Mar-06 7:32

If I'm interpreting your situation correctly...

There is no special *eof* character that you can embed in data coming through the pipe. *eof* is signalled to the process reading a pipe when the process that is writing the data closes its end of the pipe.

Regards,
Dan

Remember kids, we're trained professionals.
Don't try this at home!

9ine1-Mar-06 22:18

1-Mar-06 22:18

To induce console app function fgets() return NULL as eof encountered we must write to pipe \032\n. This works with VC compiled console app.

I close write end of pipe believe me before reading from read end of pipe, but this will not affect even windows console app which reads lines from console with fgets(). Only passing to console stdin thru write pipe \032\n induce console app to quit from fgets() returning NULL as eof was encountered! You can even leave pipe unclosed!

But with cygwin compiled application niether works!? as its compiled fgets() interprets \032\n as a string!

I that makes sence?

9ine

Dan McCormick2-Mar-06 1:33

Dan McCormick

2-Mar-06 1:33

Sorry, I don't understand what you are trying to describe.

Remember kids, we're trained professionals.
Don't try this at home!

9ine2-Mar-06 5:02

2-Mar-06 5:02

Console app which reads stdin with fgets() untill it returns NULL.
If string read, fgets returns non-zero value, if ctrl+z\n read, fgets returns NULL.

case 1: VC compiled console app!
subcase A: lunch it from command line, type strings, type ctrl+z\n to quit it
subcase B: lunch it from win app thru createprocess(), write strings thru pipe to it, write \032\n bytes seq to pipe, console app will quit!

case 2: cygwin compiled console app!
subcase A: equal to subcase A in case 1.
subcase B: equal to subcase B in case 1. except that \032\n seq is interpreted as a string and does not force to return NULL function fgets() as in case 1, subcase B!!!

What to write to pipe of case 2,subcase B, to make cygwin compiled console app fgets() function to return NULL??????

9ine

Ryan Binns1-Mar-06 17:19

Ryan Binns

1-Mar-06 17:19

You have to close the writing end of the pipe to signal an EOF to the process. This is what the command interpreter does when you press Ctrl+Z.

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

9ine1-Mar-06 22:15

1-Mar-06 22:15

I close it believe me before reading from read end of pipe, but this will not affect even windows console app which reads lines from console with fgets(). Only passing to console stdin thru write pipe \032\n induce console app to quit from fgets() returning NULL as eof was encountered! You can even leave pipe unclosed!

But with cygwin compiled application niether works!? as its compiled fgets() interprets \032\n as a string!

9ine

Ryan Binns1-Mar-06 22:50

Ryan Binns

1-Mar-06 22:50

Try sending it \004. Linux shells (which cygwin is based on) sometimes interpret Ctrl+D as an EOF character.

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

9ine1-Mar-06 23:38

1-Mar-06 23:38

useless!
fgets() compiled under cygwin interprets it as usual string!

9ine

cFile assert

act_x1-Mar-06 5:58

act_x

1-Mar-06 5:58

I am getting an assert occasionally in the following
void CFile::Write(const void* lpBuf, UINT nCount)
{
ASSERT_VALID(this);
ASSERT(m_hFile != (UINT)hFileNull);

Basically This call is from another thread (worker thread)(thread B) to write to a file and this thread does not initially create the File Object . The file object is created by the main thread (thread A ).

The above assertion happens when B tries to write to the file after A has created the file .

I have tried to put a critical section where the common function to write to the file is called but still I see the assert .

Could this be because of my thread not being able to access MFC cFile Object correctly

Also this happens occasionally 2out of 10 times .

I also see that the file is finally getting written with contents for both thread A and B but this ASSERT is worrying me .

Any ideas ?

Engineering is the effort !

Re: cFile assert

David Crow1-Mar-06 6:58

Initializing IXMLDOMTextPtr

1-Mar-06 6:58

act_x wrote:
I also see that the file is finally getting written with contents for both thread A and B...

If the possibility exists that both threads are wanting to access the file, I think you might need to wrap the read/write calls in a critical section (i.e., CCriticalSection).

"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain

"There is no death, only a change of worlds." - Native American Proverb

Re: cFile assert

Joe Woodbury1-Mar-06 10:45

Joe Woodbury

1-Mar-06 10:45

It's likely that thread A had not yet actually opened the file, or at least assigned m_hFile to the file handle, before thread B runs. Since there is an OS call, it is very likely the open operation is triggering a sleep operation which, in turn, is causing thread B to run if it has been created by that point.

I suggest not creating thread B until thread A has opened the file. An alternative is to have thread B wait on an event that will be signalled once thread A has opened the file.

A critical section should be used for read/write/close operations, but are a potential problem here since thread B could get it's time slice before thread A even enters its critical section to open the file.

Another option to look at is for thread B to open and close the file.

Also note that when you close the file, thread B must either be terminated (wait on it's handle, then close the file) or should check if the file handle is valid before performing the operation.

Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke

hanno251-Mar-06 5:26

hanno25

1-Mar-06 5:26

I will change an the content of a node in a XML-File. It is no problem, to get the specific node and its content. But to change the content of the Node I have to use the function "InsertData" from the class IXMLDOMText. Therefor I have to initialize the IXMLDOMTextPtr. But every time I try this, I get the error message, that the left part of ->"Query Interface" has to point to a class... So what's wrong with that?
Below the pasted code to make it a little bit more understandable.

Thanks, Hanno

CString fileName;
CFileFind find;
BOOL findFile;

IXMLDOMDocument m_iDocPtr;
IXMLDOMNodePtr m_iNodePtr;
IXMLDOMTextPtr m_iTextPtr;

findFile = (find.FindFile(strPath+"\\"+"*.xml",0));
while(findFile != 0) {
fileName = find.GetFilePath();
m_iDocPtr->Load((_bstr_t)fileName);
m_iFr = m_iDocPtr->createDocumentFragment();
m_iNodePtr = m_iDocPtr->selectSingleNode("//HI");

m_iNodePtr = m_iNodePtr->selectSingleNode("//Hello");
_bstr_t hello= m_iNodePtr->text;
if (atoi(hello) == 0) {
m_iTextPtr = m_iDocPtr->createTextNode("something");
m_iTextPtr->insertData(2,"something");
}
}

MultiDocTemplate initialization question

camoguard1-Mar-06 5:00

camoguard

1-Mar-06 5:00

I'm looking for some clarity here. I register two MultiDocTemplates. The only important difference between the two templates is different views.

I don't want the initial dialog that asks me to pick a template before the main window is displayed. I have an initial view already set to run.

Here's some code from my InitInstance()

// InitInstance()
m_pDocTemplate = new CMultiDocTemplate(
IDR_2DVIEW,
RUNTIME_CLASS(CCdataMFCdisplayDoc),
RUNTIME_CLASS(CChildFrame),
RUNTIME_CLASS(C2DView));
AddDocTemplate(m_pDocTemplate);

m_pDocTemplate = new CMultiDocTemplate(
IDR_OPENGL_VIEW,
RUNTIME_CLASS(CCdataMFCdisplayDoc),
RUNTIME_CLASS(CChildFrame),
RUNTIME_CLASS(COpenGLView));
AddDocTemplate(m_pDocTemplate);

// create main MDI Frame window
CMainFrame* pMainFrame = new CMainFrame;
if (!pMainFrame->LoadFrame(IDR_MAINFRAME))
return FALSE;
m_pMainWnd = pMainFrame;

// Parse command line for standard shell commands, DDE, file open
CCommandLineInfo cmdInfo;
ParseCommandLine(cmdInfo);

// Dispatch commands specified on the command line
if (!ProcessShellCommand(cmdInfo))
return FALSE;

// The main window has been initialized, so show and update it.
pMainFrame->ShowWindow(m_nCmdShow);
pMainFrame->UpdateWindow();

// Make a starter document
NewDocument();

// Create a default View

CChildFrame *pFrame = new CChildFrame();

CCreateContext context;
CCdataMFCdisplayView *pview = NULL;

context.m_pCurrentDoc = theApp.GetDocument();
context.m_pNewViewClass = RUNTIME_CLASS(C2DView);
context.m_pNewDocTemplate = theApp.m_pDocTemplate;
context.m_pLastView = NULL;
context.m_pCurrentFrame = ((CMainFrame*)AfxGetMainWnd())->GetActiveFrame();
if (pFrame->LoadFrame(IDR_2DVIEW,WS_CHILD | WS_OVERLAPPEDWINDOW | FWS_ADDTOTITLE | WS_VISIBLE, theApp.m_pMainWnd, &context))
pFrame->InitialUpdateFrame((CMyDoc*)theApp.GetDocument(),TRUE);

// nothing pertinent follows

Re: MultiDocTemplate initialization question

camoguard1-Mar-06 5:31

camoguard

1-Mar-06 5:31

I found my answer. For those interested parties, I have to handle the ON_FILE_NEW message.

Howto make a system modal application

whatever891-Mar-06 4:46

whatever89

1-Mar-06 4:46

hi,
i want to make a login application(like windows login) that blocks all other processes/windows including the task manager. the application should be a simple dialog
can anyone help plz?
thanks

Re: Howto make a system modal application

David Crow1-Mar-06 5:32

1-Mar-06 5:32

The DS_SYSMODAL style, which was for 16-bit Windows, has been "replaced" with the WS_EX_TOPMOST style.

"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain

"There is no death, only a change of worlds." - Native American Proverb

How show a Bitmap

Alfius791-Mar-06 4:20

1-Mar-06 4:20

I would want to load an image from a fixed path. This image changes every time, so I thought not include it like as a static resource. any idea?
Bye Daniel

Hamid_RT1-Mar-06 4:25

Hamid_RT

1-Mar-06 4:25

LoadImage//For Load File
CImage //Class For Load File

Alfius791-Mar-06 4:30

1-Mar-06 4:30

thanks for the answer!!
But how can show it now ?
bye

David Crow1-Mar-06 4:27

1-Mar-06 4:27

Your question is a bit unclear. Are you wanting to load a .bmp file from disk at runtime, or are you wanting to embed a .bmp file in your application at compile time?

"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain

"There is no death, only a change of worlds." - Native American Proverb

Alfius791-Mar-06 21:05

1-Mar-06 21:05

Ya !!
I'll try to explane the problem! I have two application:
- the first saves a .bmp, overwriting hold file, into a directory every about
5min, the image comes from a camera.

- the second must shows that image (something like a "refresh") pushing a button.
I tried but the image loaded doesn't change.

Can you halp me with a council?
thanks !!

David Crow2-Mar-06 3:09

2-Mar-06 3:09

Put a static control on your window/dialog, and associate a CStatic member variable with it using ClassWizard. Use SetTimer() to create a timer event every 300000ms (five minutes). In the event handler for the timer, call LoadImage() to load the .bmp file from disk. Using the returned handle, then call CStatic::SetBitmap() to associate the new bitmap with the static control. Make sense?

"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain

"There is no death, only a change of worlds." - Native American Proverb

Alfius792-Mar-06 5:06