|
Hi Sandip,
its working fine for me..thanks a lot.
|
|
|
|
|
You are welcome
Regards,
Sandip.
|
|
|
|
|
coding_ram wrote: When user clicks on more dialogue box size need to change to show more options .and button caption will renamed to less.
See here.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
DavidCrow
this is very excellent........thank you very much........so gr8
|
|
|
|
|
Hello,
I've a code snippet. Please follow the comments.
if ( !PathFileExists("C:\\TestDir") )
{
CreateDirectory("C:\\TestDir", NULL);
}
CFile cfBatchFile( "C:\\TestDir\\TestBatch.bat", CFile::modeCreate| CFile::modeRead | CFile::modeWrite );
cfBatchFile.Write( "\"C:\\windows\\system32\cmd.exe\" ipconfig>C:\\TestDir\\Test.txt", MAX_PATH );
cfBatchFile.Close();
if ( ShellExecute(NULL, "open", "C:\\TestDir\\TestBatch.bat", NULL, NULL, SW_HIDE) > (HINSTANCE)32)
{
CFile* pcfTxt = NULL;
pcfTxt = new CFile(_T("C:\\TestDir\\Test.txt"), CFile::modeRead | CFile::shareDenyNone);
INT nLogTxtLen = pcfTxt->GetLength();
}
In Debug mode (without a Debug point), the crash is shown at
pcfTxt = new CFile(_T("C:\\TestDir\\Test.txt"), CFile::modeRead | CFile::shareDenyNone);
But if I place a debug point at :
pcfTxt = new CFile(_T("C:\\TestDir\\Test.txt"), CFile::modeRead | CFile::shareDenyNone);
and then continue, no crash arises.
I guess the issue is something to do with the handle of 'C:\\TestDir\\Test.txt' file.
How could I rectify this.
Is some Sleep() required to wait for the handle to be available.
Replies would be appreciated.
Thanks
Edit/Delete Message
|
|
|
|
|
You can try using CreateProcess[^]instead of ShellExecute and then Call WaitForSingleObject[^]on the handle for process obtained from CreateProcess. Introducing Sleep might work but it will not be a good solution.
Regards,
Sandip.
|
|
|
|
|
looks like this is related to delayed write. Just because you close a file does not mean the OS will write it
the folowing is from the FlushFileBuffers documentation
Due to disk caching interactions within the system, the FlushFileBuffers function can be inefficient when used after every write to a disk drive device when many writes are being performed separately. If an application is performing multiple writes to disk and also needs to ensure critical data is written to persistent media, the application should use unbuffered I/O instead of frequently calling FlushFileBuffers. To open a file for unbuffered I/O, call the CreateFile function with the FILE_FLAG_NO_BUFFERING and FILE_FLAG_WRITE_THROUGH flags. This prevents the file contents from being cached and flushes the metadata to disk with each write. For more information, see CreateFile.
to me it looks like you need to open it in non buffering mode.
a programmer traped in a thugs body
|
|
|
|
|
I think you wanted to reply to OP
Regards,
Sandip.
|
|
|
|
|
SherTeks wrote: In Debug mode (without a Debug point), the crash is shown at...
Please explain this "crash" in more detail. Is an assertion firing? Is an exception being thrown?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
ooks like this is related to delayed write. Just because you close a file does not mean the OS will write it
the folowing is from the FlushFileBuffers documentation
Due to disk caching interactions within the system, the FlushFileBuffers function can be inefficient when used after every write to a disk drive device when many writes are being performed separately. If an application is performing multiple writes to disk and also needs to ensure critical data is written to persistent media, the application should use unbuffered I/O instead of frequently calling FlushFileBuffers. To open a file for unbuffered I/O, call the CreateFile function with the FILE_FLAG_NO_BUFFERING and FILE_FLAG_WRITE_THROUGH flags. This prevents the file contents from being cached and flushes the metadata to disk with each write. For more information, see CreateFile.
to me it looks like you need to open it in non buffering mode.
a programmer traped in a thugs body
|
|
|
|
|
I would suggest you a) use CreateProcess to run ipconfig (on its own, not in a batch file), so that you can b) redirect the standard output and standard error handles[^] of the created process to a string within your parent process.
That way, your program is using the exact same mechanism as CMD to redirect ipconfig's output to where you want to make use of it. And you don't need to mess with files and stuff.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Hi All,
I wondered if someone can shed some light on what might be going on here.
I have created the worker thread (code below) and when my system first boots up and I run through debug I find that the thread doesn't fire off the PostMessage(UWM_DATA_READ) until the buffer is full up....what I want it to do is fire it off when ever it reads in something.
The interesting part is that if I stop the application and open Hyperterminal on the same com port then close it and then rerun the application it works as I intended????
Does anyone have any ideas what is going on??????
Cheers
Jim
UINT CMyDlg::monitorThread(LPVOID pParam)
{
DWORD dwRead;
DWORD dwRes;
BOOL fWaitingOnRead = FALSE;
OVERLAPPED osReader = {0};
struct PTZCommStruct *pPTZStruct = (struct PTZCommStruct *)pParam;
osReader.hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
if(osReader.hEvent == NULL)
{
DWORD err = ::GetLastError();
pPTZStruct->pWnd->PostMessage(UWM_READER_SHUTTING_DOWN, (WPARAM)err);
return 0;
}
while(pPTZStruct->nPTZCommTerminate == 0)
{
if(!fWaitingOnRead)
{
BOOL tmp = ReadFile(m_hPTZCtrlPort, PTZbuffer, MAX_BUFFER_SIZE, &dwRead, &osReader);
if(!tmp)
{
if(GetLastError() != ERROR_IO_PENDING)
{
return 0;
}
else
{
fWaitingOnRead = TRUE;
}
}
else
{
pPTZStruct->pWnd->PostMessage(UWM_DATA_READ);
}
}
else
{
dwRes = WaitForSingleObject(osReader.hEvent, READ_TIMEOUT);
switch(dwRes)
{
case WAIT_OBJECT_0:
if(!GetOverlappedResult(m_hPTZCtrlPort, &osReader, &dwRead, FALSE))
{
DWORD dwError = GetLastError();
switch(dwError)
{
case ERROR_HANDLE_EOF:
return 0;
break;
case ERROR_IO_PENDING:
return 0;
break;
case ERROR_IO_INCOMPLETE:
return 0;
break;
case ERROR_OPERATION_ABORTED:
return 0;
break;
default:
Dump1("Serial Read Error %d\r\n", ::GetLastError());
return 0;
break;
}
}
else
{
pPTZStruct->pWnd->PostMessage(UWM_DATA_READ);
}
fWaitingOnRead = FALSE;
break;
case WAIT_TIMEOUT:
break;
default:
return 0;
break;
}
}
}
return 0;
}
|
|
|
|
|
Wow, it really seems that you like to complicate your life. If you are doing that in a separate thread, why are you using OverlappedIO ? You could simply use a blocking read that returns when data is available.
Anyway, that's not the source of your problem. From your description, it really sounds like you didn't set the comm timeouts. Thus, when you start hyperterminal, the timeout settings are changed and that's why the behavior is different afterwards. To change the comm timeouts, you can use the SetCommTimeouts[^] function.
|
|
|
|
|
Hi Cedric,
Thanks for your help, that worked straight away.....I realised I had not set the timeouts
Jim
|
|
|
|
|
Hai!
I have following doubts in my Mfc application :
1. I launch sub-application from my main dialog. I implemented shortcut keys(Alt + xx) and tab-order in both main dialog as well as in the sub application. During launch of main dialog, the shortcut keys work. but on returning from the sub-application back to main dialog the shortcut keys are not working! why?
2. I implemented Tab-order in my dialog. My dialog contains 3 radio buttons as well as 2 buttons (all are in enabled manner). On launching the dialog and pressing "Tab" button the cursor moves in between the two buttons only, it doesn't select the Radio buttons. On selecting any one of the radio buttons using mouse , now on pressing "Tab", the cursor moves to both buttons as well as the selected radio button. why does this happen is there any sollution thrugh which i can select Radio buttons using "Tab"?
Thanks!
|
|
|
|
|
1/
No solid idea - but I suspect that your first application does not have the keyboard focus. App1.exe has it when it starts. App2.exe gets the focus when it starts later. App2.exe goes away, and NOTHING has the keyboard focus (or maybe the shell does - but not App1.exe).
If you click somewhere on App1.exe, do the keys start working again?
2/
Radio buttons are a bit fiddly for tab order.
a/ Set every control style to TABSTOP.
b/ Set the GROUP style of every control
c/ Set the tab order so the radio buttons are one after each other.
d/ Clear the GROUP style of all but the first in a group of radio buttons.
Iain.
Codeproject MVP for C++, I can't believe it's for my lounge posts...
|
|
|
|
|
hi i am a fresher for WinCE and i am using createprocess to run one winceplayer application
once the commandline in the create process gets executed i want another files on the row to be executed
could anyone please help me in this regard
CreateProcess(_T("\\windows\\ceplayer.exe"),_T("c\\folder\\new.wmv"), NULL, NULL, FALSE, CREATE_NEW_CONSOLE, NULL, NULL, NULL, &processInfo);
once new is done i want next.wmv to be run
Thanks in Advance
|
|
|
|
|
Do you want to play the file one another?
then, createprocess will not help. Bcoz, createprocess WinAPI will trigger the command to the Windows Message Queue and it will come out. Application will not wait to process completed and it will execute next statement
Sethuraman.K
|
|
|
|
|
Sorry for the misguide. Mentioned earlier for ShellExecute not for CreateProcess.
Sethuraman.K
|
|
|
|
|
Thank u sethuraman.k,
Do you have any idea regarding my issue of playing the files in a row if yes guide me in this regard.
and
could you please tell me how to get the handle to the windows that have been created from createprocess(winceplayer).
so that i can use that handle to close the respective window
|
|
|
|
|
I am not sure but u just try with PROCESS_INFORMATION structure. For you "processInfo".
processInfo.hProcess contains handle to the newly created process.
Sethuraman.K
|
|
|
|
|
Just try this:
HWND hwnd;
STARTUPINFO si;
ZeroMemory( &si, sizeof(si) );
si.cb = sizeof(si);
PROCESS_INFORMATION pi;
ZeroMemory( &pi, sizeof(pi) );
if( !CreateProcess(NULL,
"C:\\Program Files\\Windows Media Player\\wmplayer.exe",
NULL,
NULL,
FALSE,
CREATE_SUSPENDED,
NULL,
NULL,
&si,
&pi ) )
{
TRACE("CreateProcess failed");
}
else
{
TRACE("CreateProcess sucess");
}
hwnd = (HWND)pi.hProcess;
ShellExecute(hwnd, "open", "d:\\del\\Dancingbaby.avi", NULL, NULL, SW_SHOWNORMAL);
TRACE("sucess");
Sethuraman.K
|
|
|
|
|
Hi Sethuraman,
I am using create process function to open a jpg file using ie in WINCE...
CreateProcess(_T("\\windows\\iesample.exe"),imFullPath, NULL, NULL, FALSE, NULL, NULL, NULL, NULL, &processInfo1);
where imFullPath is the path for a jpg file.
For opening the next jpg file,i am using create function() onemore time.
Also it is opening in a new window.
I want to open all jpg files in the same window.
|
|
|
|
|
#pragma comment(lib,"Shlwapi.lib")
I personly think the code above is to load a "dll" file。Am i right or not?
Any one can help me and explain it to me,
thanks.
Besides, i am not good at English, and if there is any grammar mistake,Please point it out directly.
thanks again.
|
|
|
|
|
The following pragma causes the linker to search for the Shlwapi.lib library while linking. The linker searches first in the current working directory and then in the path specified in the LIB environment variable.
|
|
|
|
|