C / C++ / MFC

Re: Needs Inputs regarding Printing in Plotter using MFC Doc / View Print Architecture

20-Jul-10 4:21

Provided your hardware has a Windows printer driver then you should be able to use the same (or almost the same) code to draw on the screen, on a bitmap style printer (like an old laser printer) or a vector printer (like a plotter). The only difference I can remember was having to set up the pages correctly - provided you're already scaling your output to the size of the output device it shouldn't be a problem.

Cheers,

Ash

She_Jack20-Jul-10 4:31

She_Jack

20-Jul-10 4:31

Thanks Ash for your valuable inputs

Compiler Setting VC++ 2008

T.RATHA KRISHNAN20-Jul-10 2:01

20-Jul-10 2:01

Hi!
While Debugging(Ctrl + F5) my project,all the files get compiled if change is made at one or two files. What to do to compile only the files that has changes in it?

Jaroslav Kaas20-Jul-10 2:16

Jaroslav Kaas

20-Jul-10 2:16

Try to turn on "Enable Minimal Rebuild" in C/C++ / Code Generation section.

T.RATHA KRISHNAN20-Jul-10 2:49

20-Jul-10 2:49

Hi!
It's already on.

Code-o-mat20-Jul-10 2:58

Code-o-mat

20-Jul-10 2:58

Turn on precompiled headers if not on already. Otherwise, are those files you edit maybe header files that are included in everything OR included in a header that is included in everything, like stdafx.h?

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <

Aescleal20-Jul-10 3:03

20-Jul-10 3:03

It sounds like you're entering dependency hell... To avoid that check that:

- you're not modifying something in a precompiled header. As a general rule if you MUST use precompiled headers then make sure there are only system includes in there that aren't going to change

- You haven't got some global file with system wide error messages in. It's is a recipe for disaster, don't do it. The same goes for variables and vast globs of utility functions.

- remove all extraneous guff out of headers. Don't include other headers when forward declaring something will work as well

- use parameterise from above and other decoupling patterns in your code. Don't use concrete types in most of your code, program to interface classes and only create the concrete types in one place

If you don't own a copy go and beg, borrow or steal a copy of "Large Scale C++ Design" by John Lakos. It's a bit long in the tooth and a bit quirky but it describes how to write million line + systems and not die of boredom during recompilation. Also have a look at "Exception C++" by Herb Sutter for the sections on class design which describes some of the later points I've mentioned.

Cheers,

Ash

T.RATHA KRISHNAN20-Jul-10 3:18

20-Jul-10 3:18

Hi!
I've defined two classes in the same header file. Is that a reason?

Aescleal20-Jul-10 3:25

20-Jul-10 3:25

Well for that header to cause a rebuild of everything it'd have to be:

- included in everything, either directly or through another file

- modified

If the first is true it doesn't matter whether it has 1 or 100 classes, any change will cause a massive rebuild. Having said that though I'd advocate only having one class in a header file, it makes it easier to reduce dependencies if you do.

Cheers,

Ash

T.RATHA KRISHNAN21-Jul-10 2:11

CoInitialize has not been called

21-Jul-10 2:11

Hi!
Problem is: I removed the BIOS Battery. I forgot to set the correct date and time again.

MsmVc19-Jul-10 20:41

MsmVc

19-Jul-10 20:41

Hi All

I am getting error CoInitialize has not been called.Code is here

void Ctest::OnCopyData()
{
::CoInitialize(NULL);
	COleDataSource* pSource = CopyTextList();
    if (!pSource)
        return;

	pSource->SetClipboard();

}

COleDataSource* Ctest::CopyTextFromList()
{
    USES_CONVERSION;

	CSharedFile sf(GMEM_MOVEABLE | GMEM_DDESHARE | GMEM_ZEROINIT);
	 CString str;
	int nPos=m_test.GetItemCount();
	for(int i=0;i<nPos;i++)
	{
		CString GetData=m_test.GetItemText(i,0);
		str+=GetData;
		str += _T("\r\n");
        sf.Write(T2A(str.GetBuffer(1)), str.GetLength());
        str.ReleaseBuffer();
	}
	
	 char c = '\0';
	 sf.Write(&c, 1);

	  DWORD dwLen = (DWORD) sf.GetLength();
    HGLOBAL hMem = sf.Detach();
    if (!hMem)
        return NULL;

    hMem = ::GlobalReAlloc(hMem, dwLen, GMEM_MOVEABLE | GMEM_DDESHARE | GMEM_ZEROINIT);
    if (!hMem)
        return NULL;

    // Cache data
    COleDataSource* pSource = new COleDataSource();
    pSource->CacheGlobalData(CF_TEXT, hMem);

    return pSource;
}

Please help me

KarstenK19-Jul-10 21:45

KarstenK

19-Jul-10 21:45

CoInitialize(NULL) does some stuff, so you better call it some time (100ms) before you need it to be finished.

Tip: you only need to call it one time per thread/app. Best in some startup code liek oninitdialog.

Press F1 for help or google it.
Greetings from Germany

Aescleal19-Jul-10 21:45

19-Jul-10 21:45

Try helping yourself. Here are some things to try:

- Find which line is causing the error
- When you've done that step through the code in a debugger and see if the function with CoInitialize() in is executed is before that
- Check that for every CoInitialize you've got a CoUninitialize

Cheers,

Ash

Niklas L19-Jul-10 21:45

Niklas L

19-Jul-10 21:45

Are you aware CopyTextList is called, but you supplied code for CopyTextFromList?

Also you only need CoInitialize once. Do that in your start up routine (CWinApp::InitInstance if it's MFC)

home

Process terminates spontaneously - No exception dialogue

Sauro Viti19-Jul-10 23:22

Sauro Viti

19-Jul-10 23:22

It's unuseful to call CoInitialize each time you need to use some COM object; call CoInitialize only once somewhere in your startup code instead.
Be aware that each call to CoInitialize should be balanced with a call to CoUninitialize.
From the code snippet you posted, it seems that you wrote your application using MFC, then the best places where put the calls are inside CWinApp::InitInstance and CWinApp::ExitInstance.

shoppinit19-Jul-10 11:04

Re: Process terminates spontaneously - No exception dialogue

19-Jul-10 11:04

Hi all.

My executable is suddenly disappearing after a number of hours running (variable). I have never seen this kind of behaviour before and I'm completely stumped.

What could cause my EXE to disappear discretely.

For info, I'm using XP 32 bit SP3. The app is a console app with a number of worker threads. There is no condition that would lead the program to exit cleanly (or at all for that matter).

Anyone seen anything similar?

Thanks.

Luc Pattyn19-Jul-10 12:23

Luc Pattyn

19-Jul-10 12:23

one easy way to crash silently, even on a perfect system, is by creating a fatal condition that prohibits proper signaling; a recursion ending in a stack overflow would probably be one of those. I suggest you add some logging, and periodically log some major statistics such as working set, GDI object count, etc. Make sure to regularly close the log file, so it is available after the next crash!

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.

Re: Process terminates spontaneously - No exception dialogue

shoppinit23-Jul-10 2:12

Re: Process terminates spontaneously - No exception dialogue

23-Jul-10 2:12

Many thanks for that. It does look like a stack corruption, but I'm not sure why or how to check / fix.

I used application verifier which seems to be quite good. It told me:

"the stack was corrupted when asychronous I/O was pending"

Could this cause my silent crash?

I'll try and post the full xml log from appverifier a bit later.

Luc Pattyn23-Jul-10 2:25

Luc Pattyn

23-Jul-10 2:25

maybe you are getting the next chunk of I/O data before you're finished dealing with the previous one, so your asynchronous handler (probably the receiver) is breaking in to itself sometimes (or even always). Check your code to see if that is possible, maybe add a nestinglevel counter, in pseudo-code:

int nestingLevel=0;

void myIOhandler(...) {
    nestingLevel++;
    if (nestingLevel>5) {  // or some other number
        log("warning: myIOhandler is being reentered; nestingLevel="+nestingLevel);
    }
    // your normal stuff goes here
    ...
    //
    nestingLevel--;
}

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.

Re: Process terminates spontaneously - No exception dialogue

shoppinit27-Jul-10 8:14

Re: Process terminates spontaneously - No exception dialogue

27-Jul-10 8:14

Thanks for that. I think it put me on the right track, although I was unable to check for the nesting because I didn't know where to put the increments / decrements.

I have a listening thread which listens for an RX event and reads (overlapped) the data.

Other threads can issue overlapped writes to the same port, whose access is protected with a critical section.

However, I suspect that my problem my come from the fact that I'm using the same event handle for all the instances of overlapped reads / writes.

I could be wrong about this, my understanding of overlapped I/O is limited :s

Does this make sense?

shoppinit6-Aug-10 17:41