|
Yes, the CreateProcess is being made, BOOL comes back as true, and both test programs launch. I have also put the code back in to close the thread and the process.
|
|
|
|
|
Make sure the process handle is closed AFTER the wait, else it will fail. I wrote the following small program that successfully waited on both handles. I guess I just can't see where your program is going wrong right now.
HANDLE handles[2];
STARTUPINFO sinfo;
memset(&sinfo, 0, sizeof(sinfo));
PROCESS_INFORMATION pi;
if (CreateProcessA(NULL, "C:\\Util\\ProcMon.exe", NULL, NULL, false, 0, NULL, NULL, &sinfo, &pi))
{
handles[0] = pi.hProcess;
}
CloseHandle(pi.hThread);
if (CreateProcessA(NULL, "C:\\Util\\ProcExp.exe", NULL, NULL, false, 0, NULL, NULL, &sinfo, &pi))
{
handles[1] = pi.hProcess;
}
CloseHandle(pi.hThread);
int result = WaitForMultipleObjects(2, handles, TRUE, INFINITE);
if (result < 0 || result > 1)
{
printf("Error: %d\n", result);
}
CloseHandle(handles[0]);
CloseHandle(handles[1]);
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Thanks for all your help, it really is helping me out. I will look at your code and see what I can do.
|
|
|
|
|
Compiled and ran it. The way you've nested loops, particularly if(i == progList.size()-1), made the program not do what it looks like it's supposed to do, but the [single] wait did work for me. You should be using vecHandles since what matters is the number of actual handles you actually have.
It also appears that you'd be leaking a myThreads pointer after you finish with the first wait and if you allocate memory for the second.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
I added in the if(i==progList.size()-1) to ensure I caught the last group that ran through since it would never see the else code. I have moved all the timer sutff and put it into the else block now. This clears up my timer problem. Essentially what I am looking at now is making the PROCESS_INFORMATION into a dynamic array so I can store all the pi information for later. Then I run this
CreateProcessA(NULL, commandLine, NULL, NULL, false, 0, NULL, NULL, &;sinfo, &;pi[i]);
and put it into the vector of handles for later.
vecHandles.push_back(pi[i].hProcess);
It loops here for a while, when the groupNumber changes is now goes to the else block and executes
I made another dynamic array, but this time it is an array of handles the size of (i) called myThreads
WaitForMultipleObjects(n, myThreads, TRUE ,INFINITE);
DWORD exitCode = 0;
GetExitCodeProcess(pi[i].hProcess, &exitCode);
Put the timing stuff here
The timing now works fine
Now I have to concentrate on getting this done:
ProgramDetails finDetails(currGroup, str1, str2, exitCode, kTime, uTime);
finishedList.push_back(finDetails);
Now close the handles
CloseHandle(pi[i].hThread);
CloseHandle(pi[i].hProcess);
The problem I am now facing is how to put the currGroup, str1, and str2 from each process into the final vector along with the timing information and exit code.
Have I confused things enough now? This has been a slow painful process.
|
|
|
|
|
wjeanveau wrote: This has been a slow painful process.
It almost always is. And when your done, you'll wonder why it was so hard.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Tomorrow will be a better day to look at it again. Thanks for trying.
|
|
|
|
|
Hi Guys,
I've been searching extensively over the past couple of days but still have trouble reading bits from a file. I'm trying to read the header of an MPEG ts file.
Here is what I have:
<br />
<br />
struct TS_PACKET_HEADER {<br />
unsigned int sync_byte:8; <br />
unsigned int payload_unit_start_indicator:1;<br />
unsigned int transport_error_indicator:1;<br />
unsigned int transport_priority:1;<br />
unsigned int PID:13;<br />
unsigned int scrambling_control:2;<br />
unsigned int adaptive_field_exists:2;<br />
unsigned int payload_data_exists:1;<br />
unsigned int continuity_counter:4;<br />
};<br />
<br />
...<br />
<br />
<br />
<br />
int size;<br />
unsigned char* buffer;<br />
<br />
std::ifstream inputFile("mpeg.ts", std::ios::in | std::ios::binary);<br />
if (inputFile.is_open()) <br />
{<br />
size = 4;<br />
buffer = new unsigned char[size];<br />
inputFile.seekg(0);<br />
inputFile.read( reinterpret_cast<char*>(buffer), size);<br />
<br />
TS_PACKET_HEADER header = * (TS_PACKET_HEADER*) buffer;<br />
}<br />
</char*>
The first byte reads fine but the next two bytes (payload_unit_start_indicator, transport_error_indicator, transport_priority and PID) read incorrectly.
Where am i going wrong and is there a better way to do this?
Packet header information:
http://en.wikipedia.org/wiki/Transport_stream#Important_elements_of_a_transport_stream[^]
|
|
|
|
|
Disable the padding and try.
#pragma pack(1)
struct TS_PACKET_HEADER {
unsigned int sync_byte:8;
unsigned int payload_unit_start_indicator:1;
unsigned int transport_error_indicator:1;
unsigned int transport_priority:1;
unsigned int PID:13;
unsigned int scrambling_control:2;
unsigned int adaptive_field_exists:2;
unsigned int payload_data_exists:1;
unsigned int continuity_counter:4;
};
Regards,
Jijo.
_____________________________________________________
http://weseetips.com[ ^] Visual C++ tips and tricks. Updated daily.
|
|
|
|
|
A solution more secure :
#pragma pack (push, 1)
....
#pragma pack (pop)
An other things, your structure size is : 33 bits.
Align it to 40 bits or 64 bits by adding a fake data at the end.
bye...
...
|
|
|
|
|
Thanks for all your replies.
I've read up on it a bit and have tried both pragma pack(1) before the struct and pragma pack(push, 1) ... pragma pack(pop) around the struct and both have not worked.
This[^] also verifies what you have said.
I havent disable padding though. I've look for how to do this but cant find it for either GCC of Visual Studio. I've also had a look at this[^] to no avail.
The header was incorrect. I've removed payload_data_exists:1 and made adaptive_field_exists:2
http://www.erg.abdn.ac.uk/research/future-net/digital-video/mpeg2-trans.html[^]
|
|
|
|
|
I have to wonder if this structure is correct:
botnet wrote: // header structure
struct TS_PACKET_HEADER {
unsigned int sync_byte:8;
unsigned int payload_unit_start_indicator:1;
unsigned int transport_error_indicator:1;
unsigned int transport_priority:1;
unsigned int PID:13;
unsigned int scrambling_control:2;
unsigned int adaptive_field_exists:2;
unsigned int payload_data_exists:1;
unsigned int continuity_counter:4;
};
The reason I ask is that it contains 33 bits, so it would read 8 bytes from the file.
Also, there are many types of MPEG - MP3, MP4, MPEG, etc.
You might want to check for the file format at www.wotsit.org
Perhaps there are supposed to be some padding bits in there somewhere?
Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
|
|
|
|
|
Hi all,
I am writing an MFC program (VC++ 6) that generates a report and supposedly able to print it out. The report is fine, but somehow it prints a blank page to the printer. After days of debugging the code, I still cannot locate the problem. This is why I can't simply post the problematic code here, I don't know which part is the problem! (Please forgive me if this is really not the right way to ask)
Here I created a (much) simplified code that simulates my problem. It could be because:
1. It is SDI-based program, but I deleted the CDocument class since I don't need it.
2. I use Easy! Reports (http://www.codeproject.com/KB/miscctrl/easyreports.aspx[^]) to generate the report
3. The report is shown using a custom control (http://www.codeproject.com/KB/docview/dfv.aspx[^])
4. Lastly, I am trying to print without using doc/view framework (http://www.codeproject.com/KB/printing/printing_wo_docview.aspx[^])
Could anyone please help me here. From what I understand, all I have to do is prepare the device context for printing (using number 4 above) and send it to the report generator function (number 2). Yet, it prints a blank page.
If anyone could please take a glance and point me to the right direction, I would really appreciate it. Thanks.
Download link: http://rs324.rapidshare.com/files/121245334/TestReport.zip[^]
|
|
|
|
|
Hi, I will afterwards take a look to your code.
On the other hand...
1) The document should not be a problem to print or not to print.
2) If you are seeing the things in your screen, the easy reports should not be the problem
3)...
4) It is ok, you can do it.
Some check-points I faced in one project...
Are you taking care on your MAPMODE and page Orientation? (screen are pixels with a meaning, but printers... this is another world)
Are you taking care about the m_rectDraw and page offsets?
Are you using CreaterPrinterDC??
ADD: You may want to take a look here[^]
Regards.
--------
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
Rating helpfull answers is nice, but saying thanks can be even nicer.
modified on Monday, June 9, 2008 2:21 PM
|
|
|
|
|
Hi,
Yes, following the article number 4, I use CreaterPrinterDC and initialize m_rectDraw and m_nCurPage.
I do not change the page orientation nor the MAPMODE (I figure I can deal with this later IF the printed results is incorrect, yes?)
Regards,
jsix
|
|
|
|
|
Orientation should be portrait by default, but depending on MAPMODE you can probably see nothing printed.
Take a look into GetDeviceCaps and pInfo.
Printing is not so easy. I needed between 3 and 4 weeks to get output in three different printers correctly.
Regards.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
Rating helpfull answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Thanks for the tips, but actually I once trying inserting one DrawText function and it printed out the text fine, but the report was not printed. So I am guessing that the parameter for the printer were correct already and problem is somewhere else. Did you try compiling and printing my report?
(I know printing is not easy. But I want to have something printed out first, correctly or not, before experimenting/learning other parameters).
|
|
|
|
|
I don't have VC++ installed in this laptop so it is difficult for me to compile/debug. I am just answering by heart (I can have errors).
I have taken a look into your code and...
bPrintingOK &= dc.StartDoc(&docinfo);
bPrintingOK &= dc.StartPage();
((CReportView*)theApp.m_pReportView)->OnPrint(&dc, &Info);
bPrintingOK &= dc.EndPage();
((CReportView*)theApp.m_pReportView)->OnEndPrinting(&dc, &Info);
Why are you mixing a dialog to set printing parameters but then printing from your other view? Wouldn't be easier to set parameters and print directly there?
Chris' article is to print within a dialog. So, as you said, using a DrawText in the dialog prints it works.
Sending DCs and pInfos from one place to another is not so good idea. I think the problem can be there
Regards.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
Rating helpfull answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Ah, so you can't compile it now, I see. Could you please try it later?
In Chris' article, it shows that the parameters are set from CMyDialog::Print()
and pass them to the view class.
OnPrint(&dc, &Info);
Anyway, I tried setting/calling the print dialog from within the view, same result: empty page.
|
|
|
|
|
My private laptop is broken and in this (work) I have not the VC++, I won't be able to compile.
On the other hand...
Quote from the article:
In order to keep the MFC Doc/View feel I recomend providing helper callback functions OnBeginPrinting, OnEndPrinting and OnPrint similar to the CView versions. A CDC and a CPrintInfo object is passed into each of these functions. You will have to provide these functions yourself.
Read carefully the introduction. These functions are to be made into the dialog.
Other thing that you can make is to track down your code when you call the OnPrint of your recport view, and see if the pDC there is getting the right values (think that I guess is your problem).
What are you using your ReportViewDlg for?
Regards.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
Rating helpfull answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I use the ReportViewDlg to show the report in the custom control (see number 3 in my initial post).
I think the pDC is correct. Here is the function where I inserted the DrawText that prints OK.
void CReportView::OnPrint(CDC* pDC, CPrintInfo* pInfo)
{
CReportDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);
pDoc->Draw(pDC);
CRect printArea;
printArea.SetRect(0, 0, pDC->GetDeviceCaps(HORZRES), pDC->GetDeviceCaps(VERTRES));
pDC->DrawText("My Test is OK.", printArea, DT_NOPREFIX | DT_WORDBREAK);
CScrollView::OnPrint(pDC, pInfo);
}
|
|
|
|
|
Joe Smith IX wrote: CReportDoc* pDoc = GetDocument(); ASSERT_VALID(pDoc); pDoc->Draw(pDC); // This does not print anything
 
I thought you were not using Doc-View Framework....
pDoc is not the same as pDC...
I think you are complicating yourself more than necessary and that you don't have your concepts clear. In the projec I downloaded there was nothing in the CTestReportView.
Anyways... the second snippet prints... so what you should do is continue up from there, getting your parameters and sending them to pDC.
pDoc gives no support to printing, printing is something that depends on the view.
I am going to have dinner and see a film, take a look in what you are really doing, make some tests and answer me tomorrow. Maybe I won't answer till wed (depending on Football tomorrow, Spain plays in the europa's cup and I am meeting some friends to see the match with some beers :P, I know when I'm going out, but not when I'm coming back  )
Good luck with your tests
Regards.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
Rating helpfull answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I am NOT using Doc/View framework.
The view/doc I am using are the classes from the custom control I am using (number 3 in my original post).
The function that prints on the screen is
void CReportView::OnDraw(CDC* pDC)
{
CReportDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);
pDoc->Draw(pDC);
}
The pDC above is pointing to the screen, right? My thinking is that if I use the use printer's pDc, then it should print out on the printer, yes?
void CReportView::OnPrint(CDC* pDC, CPrintInfo* pInfo)
{
CReportDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);
pDoc->Draw(pDC);
CScrollView::OnPrint(pDC, pInfo);
}
|
|
|
|
|
Quote from the file EasyReport.cpp
/*****************************************************************
*
* method :void CEasyReport::Start(void)
*
* parameters : none
*
* returns :
*
* description: Start the report generation. Create all the fonts, etc
* Try and get the printer device context, If no printer is set up as
* the default printer on the system, create a screen device context.
*
****************************************************************/
So you have to make that your code attach the printerDC you are getting to the m_printerDC, that printerDC is being used in the CEasyReport::CEasyReport (), in the CEasyReport::WriteParagraph (), in the CEasyReport::Start () and the CEasyReport::End (). But watch out, the definition is an HDC so maybe you can not use your CDC* directly.
I suggest you to read another time carefully the articles whose code you are using, go slow through the code they provided because the support for printing is in the pre-done code you are using. You just have to find your way to correctly connect them. If I were you I would try to contact with the autors ask them directly.
Good Luck 
Regards.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
Rating helpfull answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Pretty cool. I dl'd and printed blank pages too! Lemme poke it with a stick...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
