C / C++ / MFC

Print command to printer using PostMessage?

24-Jul-11 7:08

You can try Extended CComboBox[^] control ...

AnayKulkarni20-Jul-11 2:29

AnayKulkarni

20-Jul-11 2:29

Hello to all,
I have written a VC++(MFC) application in which one of our USB connectivity device gets connected to computer and I continuously collect the data from that device. I display that data on screen and also when I give print command to printer through my application then that data gets printed on paper.

Now my problem is that, when I give print command to printer then it interrupts or stops data collection from the device untill the printing process gets completed but due to this we loose data from the device. So is there any way to handle printing process independently? Means can we give print command to printer using "PostMessage" or using seperate thread so that it will not stop data collection from device? or is there any other way to do this?

This is really very very urgent so please please help me out.

Thanks and Regards

Anay

Re: Print command to printer using PostMessage?

Richard MacCutchan20-Jul-11 2:33

CTabCtrl - retrieving tab's title text

20-Jul-11 2:33

I would suggest using threads or even a separate program to do the printing. A lot depends on where you are storing the data that you are collecting.

The best things in life are not things.

rp_suman20-Jul-11 1:11

rp_suman

20-Jul-11 1:11

How to get the title text CTabCtrl's tabs?
The following code is crashing at the last line:

TCITEM tcItem;<br />
tcItem.mask = TCIF_TEXT;<br />
m_ReportTabCtrl.GetItem(ID_PANE_FOUND, &tcItem);<br />
CString csText = tcItem.pszText;<br />

Thanks & Regards

--
"Programming is an art that fights back!"

Re: CTabCtrl - retrieving tab's title text

Richard MacCutchan20-Jul-11 1:32

Re: CTabCtrl - retrieving tab's title text

20-Jul-11 1:32

You did not initialise your TCITEM structure properly; see the MSDN documentation here[^]. It would be better to check the return value from all Windows function calls rather than just assuming that they have succeeded.

The best things in life are not things.

rp_suman20-Jul-11 2:23

rp_suman

20-Jul-11 2:23

Thanks, It is working after initializing all the required members tcItem.pszText and tcItem.cchTextMax along with tcItem.mask.

--
"Programming is an art that fights back!"

VC6 to VC2008 migration

_Flaviu19-Jul-11 19:34

Re: VC6 to VC2008 migration

19-Jul-11 19:34

I have a relativ simple (SDI) VC6 project that, because system tray notification ( showing ballon ) I have to compile in a newly environment ... I choose VS2008. I prefer to compile in a dynamic MFC library but I front with several linking errors :

error LNK2005: __invoke_watson already defined in msvcrtd.lib(MSVCR90D.dll)	libcmt.lib	Der
error LNK2005: __encode_pointer already defined in msvcrtd.lib(MSVCR90D.dll)	libcmt.lib	Der
error LNK2005: __decode_pointer already defined in msvcrtd.lib(MSVCR90D.dll)	libcmt.lib	Der
error LNK2005: __configthreadlocale already defined in msvcrtd.lib(MSVCR90D.dll)	libcmt.lib	Der
error LNK2005: __amsg_exit already defined in msvcrtd.lib(MSVCR90D.dll)	libcmt.lib	Der
error LNK2005: __initterm_e already defined in msvcrtd.lib(MSVCR90D.dll)	libcmt.lib	Der
error LNK2005: _exit already defined in msvcrtd.lib(MSVCR90D.dll)	libcmt.lib	Der
error LNK2005: __exit already defined in msvcrtd.lib(MSVCR90D.dll)	libcmt.lib	Der
error LNK2005: __cexit already defined in msvcrtd.lib(MSVCR90D.dll)	libcmt.lib	Der
error LNK2005: __unlock already defined in msvcrtd.lib(MSVCR90D.dll)	libcmt.lib	Der
error LNK2005: __lock already defined in msvcrtd.lib(MSVCR90D.dll)	libcmt.lib	Der
error LNK2005: __XcptFilter already defined in msvcrtd.lib(MSVCR90D.dll)	libcmt.lib	Der
error LNK2005: ___xi_a already defined in msvcrtd.lib(cinitexe.obj)	libcmt.lib	Der
error LNK2005: ___xi_z already defined in msvcrtd.lib(cinitexe.obj)	libcmt.lib	Der
error LNK2005: ___xc_a already defined in msvcrtd.lib(cinitexe.obj)	libcmt.lib	Der
error LNK2005: ___xc_z already defined in msvcrtd.lib(cinitexe.obj)	libcmt.lib	Der
error LNK2005: "void __cdecl terminate(void)" (?terminate@@YAXXZ) already defined in msvcrtd.lib(MSVCR90D.dll)	libcmt.lib	Der
error LNK2005: ___set_app_type already defined in msvcrtd.lib(MSVCR90D.dll)	libcmt.lib	Der
error LNK2005: __setmbcp already defined in libcmt.lib(mbctype.obj)	msvcrtd.lib	Der
fatal error CVT1100: duplicate resource.  type:MANIFEST, name:1, language:0x0409	CVTRES	Der
fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt	Der	Der

I never used VS2008, what should I do to solve the problem ?

Stefan_Lang19-Jul-11 22:04

Re: VC6 to VC2008 migration

19-Jul-11 22:04

I got similar errors when moving from 2003 to 2010 recently. The cause was a static library that was part of my project that bound the runtime library statically rather than dynamically. For some reason this was never a problem before, but VS 2010 didn't like it.

My advice is check the libs that are part of your solution and make sure they all use the same settings regarding the runtime library being used. note that it doesn't matter whether the lib is bound statically or dynamically to your executable - the main point is that all libs must use the same version of the runtime library. (and I believe the same is true for the choice of MFC library)

_Flaviu20-Jul-11 4:05

Re: VC6 to VC2008 migration

20-Jul-11 4:05

Thank you, I will try.

_Flaviu20-Jul-11 19:51

Why debugging doesn't work properly when I choose "USE PRECOMPILED HEADER"?

20-Jul-11 19:51

Was the libcmt.lib problem : in project settings, link, input, I ignore libcmt library and goes almoust fine ... I set manually manifest.xml, and didn't like it to VS2008.

Cold_Fearing_Bird19-Jul-11 19:01

Re: Why debugging doesn't work properly when I choose "USE PRECOMPILED HEADER"?

19-Jul-11 19:01

<< VS2008 professional edition >>
If I use precompiled header "stdafx.h", sometimes debugging just doesn't work well, some of the variable value don't show up. Then I turned off using precompiled file, everything gets back to normal.It's only my prolbem? or does it ever happen to you, could there be a solution ?

Richard MacCutchan19-Jul-11 21:44

Re: Why debugging doesn't work properly when I choose "USE PRECOMPILED HEADER"?

19-Jul-11 21:44

This is most unlikely; what is more likely is that you have some old information in your .PCH file (or in stdafx.h) that is causing the problem. Try doing a CLEAN and rebuild and check again what is happening. It would be useful to look closely at exactly what just doesn't work well and give specific details if it happens again.

The best things in life are not things.

Cold_Fearing_Bird19-Jul-11 22:17

Re: Why debugging doesn't work properly when I choose "USE PRECOMPILED HEADER"?

19-Jul-11 22:17

Thanks for reply, I thihnk you're right.
Although it was the variables that from my cpp file didn't show up and leave the poor blue-cube(stands for variable)lonely there, I still believe it's my stdafx.h going awry.

here's my stdafx.h

#include <windows.h>
#include <windowsx.h>
#include <iostream>
#include <iomanip>
#include <string>
#include <vector>
#include <map>
#include <complex>
#include <fstream>
#include <sstream>
using namespace std ;
#include <strsafe.h>
#include <GdiPlus.h>
using namespace Gdiplus ;
#include <CommCtrl.h>
#include <cassert>



class __Init_win32_app
{
private:
	ULONG_PTR m_gdiToken ;
public:
	__Init_win32_app() ;
	~__Init_win32_app() ;
private:
	BOOL InitCommonControls() ;
} ;

//stdafx.cpp

#include "stdafx.h"

#pragma comment( lib, "gdiplus.lib" )
#pragma comment( lib, "comctl32.lib" )
#pragma comment(linker,"\"/manifestdependency:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")

__Init_win32_app::__Init_win32_app()
{
	GdiplusStartupInput gdiplusStartupInput;
	GdiplusStartup(&m_gdiToken, &gdiplusStartupInput, NULL);
	InitCommonControls() ;
}
__Init_win32_app::~__Init_win32_app()
{
	GdiplusShutdown(m_gdiToken);
}

BOOL __Init_win32_app::InitCommonControls()
{
	INITCOMMONCONTROLSEX iccex ;
	iccex.dwSize = sizeof( iccex ) ;
	iccex.dwICC = 0													
//		|	ICC_ANIMATE_CLASS								// animate
//		|	ICC_BAR_CLASSES									//tool bar, status bar, track bar, tooltip
//		|	ICC_COOL_CLASSES									//re bar
//		|	ICC_DATE_CLASSES									// data and time picker
//		|	ICC_HOTKEY_CLASS								//hot key
//		|	ICC_INTERNET_CLASSES						// IP
//		|	ICC_LINK_CLASS										// hyper link
		|	ICC_LISTVIEW_CLASSES						// list view, header
//		|	ICC_NATIVEFNTCTL_CLASS					// navtive font
//		|	ICC_PAGESCROLLER_CLASS				// pager
//		|	ICC_PROGRESS_CLASS							// progress
		|	ICC_STANDARD_CLASSES						// button ,edit, static, listbox, combobox, scrollbar
//		|	ICC_TAB_CLASSES									// tab, tooltip
//		|	ICC_TREEVIEW_CLASSES						// tree view, tooltip
//		|	ICC_UPDOWN_CLASS								// up down
//		|	ICC_USEREX_CLASSES							// ComboBoxEx
//		|	ICC_WIN95_CLASSES								// animate, header, hotkey, list_view, progress bar, status bar, 
		;																			//tab, tooltip, toolbar, trackbar, tree_view, up down
	return ::InitCommonControlsEx( &iccex ) ;
}

__Init_win32_app win32_app ;

Could you help me with it?

Stefan_Lang19-Jul-11 22:48

Re: Why debugging doesn't work properly when I choose "USE PRECOMPILED HEADER"?

19-Jul-11 22:48

Umm, does this even link? AFAIK the PCH file is simply the object file created from stdafx.cpp, and if that were true you would be binding the implementation of your class __Init_win32_app to every object file in your project, thus causing error 2005 (' ... already defined in ...'). But I may be wrong.

In any case, I see no reason at all to put your class definition in there. Try moving your class declaration to a separate header and the implementation to a separate source file. The rest of your stdafx.h looks ok to me. stdafx.cpp should only contain the include statement.

Cold_Fearing_Bird19-Jul-11 23:14

Re: Why debugging doesn't work properly when I choose "USE PRECOMPILED HEADER"?

19-Jul-11 23:14

Thanks for improving my codes. Laugh | :laugh:

It can be compiled, but I would love to keep the code anomaly to minimum, in case something undefined jumps out of nowhere, and we both know it's a time eater,HOHO.

Richard MacCutchan19-Jul-11 23:52

Re: Why debugging doesn't work properly when I choose "USE PRECOMPILED HEADER"?

19-Jul-11 23:52

Cold_Fearing_Bird wrote:
Could you help me with it?

For a start take all that extraneous code out of stdafx.cpp; that file should only contain the very first statement (#include "stdafx.h"). Also remove all the '__Init_win32_app' class definitions from stdafx.h and place them in a local project include file.

The best things in life are not things.

Stefan_Lang19-Jul-11 22:11

Re: Why debugging doesn't work properly when I choose "USE PRECOMPILED HEADER"?

19-Jul-11 22:11

I doubt this is related to using PCH. More likely, the debugging information simply wasn't up to date. Changing the setting to use or not use a PCH will force a complete rebuild that of course created the neccessary information and that is why your problem was solved after changing that.

Unfortunately VS was never really good at keeping the debug information accurate. You sometmes do have to force a complete rebuild, either by doing a Clean first, or just by choosing Rebuild All.

P.S.: one of the possible reasons for your debug information to mess up is when files change that are not actually part of your solution, e. g. header files from third party libraries. VS obviously does not check these files, and I never managed to find a setting to fix that. Back in the time when we were still using makefiles I'd simply add a dependency, but I have no idea what to do nowadays...

Cold_Fearing_Bird19-Jul-11 22:22

Re: Why debugging doesn't work properly when I choose "USE PRECOMPILED HEADER"?

19-Jul-11 22:22

My header files( stdafx.h, stdafx.cpp, some routine files) are in a different folder than the project folders I usually work on. Does that tend to cause problem?

Stefan_Lang19-Jul-11 22:26

How to turn off the disassemble functionality

19-Jul-11 22:26

No, as long as you don't get a 'file not found' error you're good. You could put any file anywhere as long as you provide the neccessary paths where to look for them. And you'll notice if something is missing as soon as you try to compile (or link).

Cold_Fearing_Bird19-Jul-11 5:48