ATL / WTL / STL

Re: SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\

25-Jul-11 3:33

Are you sure that lpData is big enough to hold the returned value? What is the value of buffersize when you call the query function? Also, I do not see a push_back() method for either CString or CStringT classes; are you sure this is what you mean?

The best things in life are not things.

MicroVirus6-Sep-11 2:18

MicroVirus

6-Sep-11 2:18

I'm guessing both lpData as applist need to be wide (unicode). You are using the wide version of RegQueryValueEx so for string values you are (I think) returned the unicode/wide version.

Help regarding method WNetCancelConnection2

tasumisra18-Jul-11 23:42

tasumisra

18-Jul-11 23:42

Hi Guys,

I am having one application(Windows service) that was working fine with VS 2003,i am compiling this application with Visual Studio pro 2008 and getting linker error for WNetCancelConnection2.

To supress linker error i have added MPR.LIB,it all work fine but whe its been deployed to server it was giving error
"Dependent Assembly Microsoft.VC80.MFC could not be found and Last Error was
The referenced assembly is not installed on your system ".

can somebody help me here.

thanks

vikas da

Re: Help regarding method WNetCancelConnection2

Richard MacCutchan19-Jul-11 0:35

Problems with Docking Toolbars

19-Jul-11 0:35

You need to get the runtime libraries installed on your server. See the link in this message[^].

The best things in life are not things.

Syamlal S Nair18-Jul-11 17:59

Syamlal S Nair

18-Jul-11 17:59

Hi,

I have been trying to adopt certain new MFC classes(version-10.0) into my application (written based on MFC 7.0 originally).
A brief of the context is as below.

I have an application with the main window class, CMainFrame derived from CMDIFrameWnd, and the toolbars created from CToolBar.

These ToolBars are fitted into objects of a class called CMyDialogBar. CMyDialogBar is derived from CDialogBar (which is a child of CControlBar, as you know).

In order to serialize the dock information, in one of the Dlls of my application, CDockState object is used in the code. A pointer to the application's main window is retrieved using AfxGetMainWnd() and dynamic casted to CFrameWnd, and methods like GetDockState() etc. are called against it. Also, CControlBarInfo pointer is used to get each control bar information from CDockState object, and remove a couple of them from the list based on some specific logic before
saving it for persisting.

Now starts the real problem.

I need to incorporate CMFCToolBar instead of CToolBar, and the application's main window is changed to derive from CMDIFrameWndEx instead of CMDIFrameWnd.CMyDialogBar class is now altered to derive from 'CDockablePane' (instead of CDialogBar) as I found in some forums.

I get debug assertion failures, wherever CControlBarInfo is used, and wherever GetDockState() or SetDockState() is called since those methods refer to CControlbar objects/pointers internally.

Sample code from dll, is as shown here:

void CDialogBarService::RestoreState()
{
	CFrameWnd* pWnd = DYNAMIC_DOWNCAST( CFrameWnd, OldStyleAfxGetMainWnd());
	pWnd->PostMessage( WM_STATUS_UPDATE, 0, 0);
	
	ASSERT( pWnd != NULL);

	// Restore from user object
	//
	CDockState state;

	CMyContext context;
	CMwSession session;
	CProxyUser*	pUser = session.GetUserProxy();
	if ( pUser != NULL && pUser->GetInstrProfileContext( NAME_LAYOUT_DIALOG_BAR_SERVICE, context) )
	{
		if ( context.Exists( NAME_TOOLBAR_STATE) )
		{
			CByteArray data;
			if ( context[NAME_TOOLBAR_STATE].Get( data) )
			{
				// create a RawByteFile with a pointer to the byte array
				// reqd as the archive object requires a file not an array
				//
				CRawByteFile file( data.GetSize(), data.GetData());

				// create an archive object, set to LOAD
				//
				CArchive ar( &file, CArchive::load);

				// extract the toolbar state from the archive
				//
				state.Serialize( ar);
			}
		}

		// Do some pre-processing to ensure that we get no errors
		//
		// If our toolbars are hidden they are not restored and so we can get
		// error conditions in SetDockState.  This code just purges
		// the saved state of any toolbars that don't exist at this time
		//
		for ( int i = state.m_arrBarInfo.GetUpperBound(); i >= 0 ; i-- )
		{
			CControlBarInfo* pInfo = reinterpret_cast< CControlBarInfo*>( state.m_arrBarInfo[i]);
			ASSERT( pInfo != NULL);
			pInfo->m_pBar = pWnd->GetControlBar( pInfo->m_nBarID);
			if ( pInfo->m_pBar == NULL )
			{
				CControlBarInfo* pState = reinterpret_cast< CControlBarInfo*>( state.m_arrBarInfo[i]);
				state.m_arrBarInfo.RemoveAt( i);
				delete pState;
			}
		}

		// Finally set toolbar state		
		pWnd->SetDockState( state);
		
	}
}

In the above sample code, i even tried to replace CFrameWnd pointer to CMDIFrameWndEx pointer, but the method call SetDockState() was giving compilation error, since it is made protected in the new MFC class hierarchy. Since i am standing in a dll, i cannot have my CMainFrame class instantiated here, to call a public method or overridden member function, which in turn can invoke the protected member.

Questions-

1. Which class i can use for replacing CControlBarInfo in the context of DockablePanes?

2. Why those methods like SetDockState(), GetDockingManager() etc. made protected for CMDIFrameWndEx class in new hierarchy?

3. Is there any other mechanism/classes using which i could achieve the above persistence?

Thanks in advance.

Regards
Syamlal

SYAMLAL

Compiling with VS2010

Kyudos14-Jul-11 13:39

14-Jul-11 13:39

I recently switched to VS2010 and its a big pain. I understand it is more standards compliant etc., but it also seems incredibly fragile. The linker crashes often, the thing that compiled fine yesterday won't compile today, despite me not changing anything. If I leave my compilation running while locking the computer VS2010 crashes. All in all the whole product seems flaky.

Anyway to specifics:

How can I get rid of the MSB8012 warning? Why does MS insist on thinking it knows what I want better than I do? Output a DLL to a non-standard location and it starts freaking out. Also doesn't seem to like relative paths much in these settings.

Is there a way to turn off the use of the path macros?

I also keep getting:

error LNK1318: Unexpected PDB error; ACCESS_DENIED (15)

Even though the PDB in question is for a different product and nothing is using it and it isn't read-only.

Any one know anything about that?

Bring back VS6! Roll eyes | :rolleyes:

Albert Holguin15-Jul-11 3:54

Re: Compiling with VS2010 [modified]

15-Jul-11 3:54

Make sure you install the service packs (I do believe SP1 is out for VS2010), I use VS2008 and have not major complaints after the first service pack.

Kyudos wrote:
How can I get rid of the MSB8012 warning?

Use a #pragma warning( disable: WARNING_NUMBER ) statement

Kyudos wrote:
Output a DLL to a non-standard location and it starts freaking out.

I do this all the time in VS2008 and it has no problem with it, wouldn't imagine they changed that very much from one release to another.

Kyudos wrote:
error LNK1318: Unexpected PDB error; ACCESS_DENIED (15)

These are the type of random errors you sometimes experience pre-service packs... Laugh | :laugh:

I hope your experience with VS2010 gets better, I've seen a lot of improvements from the usability stand point and the better standard C++ compliance is certainly a great step forward for MS. Good luck! Smile | :)

Kyudos17-Jul-11 17:50

17-Jul-11 17:50

Thanks Albert - I downloaded SP1 and now have a different set of problems!

At first my application would crash the development environment every time I tried to debug (F5),
so I decided to do a full rebuild.

Now one of my Fortran libraries won't compile, because it appears to be looking for a dependent library in a weird place:

fatal error LNK1181: cannot open input file 'C:\Program Files\Microsoft Visual Studio 10.0\Common7\...'

I can't seem to find anything that would make it look there for lib files.

Any ideas?

EDIT: Ah - Fortran problem!

Solution[^]

modified on Sunday, July 17, 2011 11:56 PM

Albert Holguin18-Jul-11 4:33

18-Jul-11 4:33

So you got your linker problems resolved?

Kyudos18-Jul-11 11:13

18-Jul-11 11:13

Yeah, finally, thanks. Will just have to wait and see if SP1 improves the general stability - I've had the dev-env crash a couple of times already though.

Albert Holguin18-Jul-11 11:19

18-Jul-11 11:19

They usually do, what OS are you running on?

Kyudos19-Jul-11 10:40

19-Jul-11 10:40

XP SP3 at the moment, but we'll be looking to move to Win7 in the near future.

Albert Holguin19-Jul-11 11:32

19-Jul-11 11:32

Wow, I've never really had many problems with stability in XP. I did have quite a few in Win7 and Vista up until the initial SPs in VS2008.

ATL CString

hrishi32110-Jul-11 18:49

10-Jul-11 18:49

Hello All,

here I have another 2 doubt of ATL::CString

1. I am not able to overridden ATL::CString class, in a proper way. Is it necessary to override all the methods of this class? I want to override only a few actually.

2. for all the character operation, it warns me " conversion from 'wchar_t' to 'char', possible loss of data"

char tt = strTemp[0];

Is there any way to convert 'wchar_t' to 'char' as in global way, so that i don't need to typecast it everytime like

char tt = (char)strTemp[0];

thanks in advance
hrishi

Cool_Dev10-Jul-11 21:02

Cool_Dev

10-Jul-11 21:02

I guess your project setting in UNICODE. If so, CString will be using wide char (wchar_t) to manipulate strings. The problem is, you are treating them as multibyte characters (char). I suggest you to use TCHAR type instead of hard coding char & wchar_t, as it can be used well in both unicode and multibyte configurations.

hrishi32110-Jul-11 21:18

10-Jul-11 21:18

Thanks for your reply Smile | :)

what about setting the project as character set : Not set,
in this case, as your suggestion, do I need to replaced all char to TCHAR in the whole project. Thats a lot Smile | :)

. . I was trying to avoid much touch in the project implementation Smile | :)

How about having my own class CMyString : public ATL::CString, can i do something in this way to avoid less touch to the project code ? Please note that the current project uses char not wchar_t. Project setting could be change according to our convenience

thanks in advance
hrishi

Cool_Dev11-Jul-11 4:36

Cool_Dev

11-Jul-11 4:36

1. If character set is 'Not Set', i think char will work.

2. CMyString can be alright. Write it to take char only, and internally convert them to wchar_t if the Character Set is 'Unicode' (using APIs like MultiByteToWideChar) and let the CString base class to do the string operations. This will help you to retain all the char types in existing code, provided you are replacing all usage of CString with CMyString. And the implied issue is that you won't be able to manipulate non-english characters with CMyString.

hrishi32111-Jul-11 17:43

11-Jul-11 17:43

Thanks for your reply, It was of great help.

I followed the same way as you suggested. But found a very interesting problem. Following is the explanation:
I should be able to use + operator like below..

CMyString strTemp;
strTemp = "aa" + strTemp;

And for this I need to overload the +operator.(Reason:: I get a error which says::

error C2678: binary '+' : no operator found which takes a left-hand operand of type 'const wchar_t [3]'

I am not able to find a appropriate way to call the operator+ of the base class, or any other way to solve the same. [ All I need is, inside operator+ overloading , to convert the char to wchar and then pass it to the base class]

Please help me.

thanks in advance
Hrishi

Richard MacCutchan11-Jul-11 22:26

11-Jul-11 22:26

I don't understand why you do not use the CStringT[^] class, which already includes the code for overloading the + operator. What extra functionality does your derived class offer that CStringT does not already include?

The best things in life are not things.

BWake8-Aug-11 5:47

BWake

8-Aug-11 5:47

I think you need to bite the bullet and convert all your char variables and constants to TCHAR. If you do not, you will continue to have problems like this. If it were easy to solve the multi-byte to Unicode to multi-byte character conversion issues that solution would be part of the CString class.

The changes you need to make are mechanical. You need to put _T() around all your string and character literals. You need to change all your char variables to TCHAR.

I don't know how big your project is, or if you have access to all the source. I suspect you have spent more time trying to avoid the issue than a proper fix would require.

Richard MacCutchan11-Jul-11 5:03

11-Jul-11 5:03

You cannot use casting to convert from a large element type to a smaller one without potential loss of data, you must use some form of conversion. If you stick with the default CString[^] class it will handle either char or wchar_t depending on your project settings. If your project needs to use both Unicode and MBCS then you need to provide conversion functions at the appropriate parts of your application. If it will only ever use one or the other but you need to provide a version that will handle each type then use TCHAR as the type for all your character variables and _T("constant string") macros for all constants. That way you can simply rebuild your project to handle the appropriate encoding.

The best things in life are not things.

hrishi32111-Jul-11 17:45

11-Jul-11 17:45

thanks for your reply.
TCHAR was a great help.
I am facing another problem, while implementing the same. could you please take a look and follow the above comments of mine.
thanks in advance

Hrishi

Avoiding MFC CString

hrishi32110-Jul-11 16:58

10-Jul-11 16:58

Hello all,

I need to avoid MFC from my existing project, and convert to ATL. I am using STL for the most of the conversion (defining my own class for MFC type)
CString has been use extensively in the project. So I guess its better to implement my own CString class. So that I dont need to touch all the implementation.

I found out that ATL also has CString

typedef CAtlString CString;

So, if project setting avoids MFC, then CString will be refererd from this ATL CString class. But the problem is I need to touch and convert many code like

"xx"  to  L"xx"
char to wchar_t

Can I have a efficient way, in order to avoid touching much implementation, and character code supportness.
Shall I override this ATL CString class? or better right my own?
considering about the supporting of character type (Unicode/others), could you Please suggest me, or advice me.

thanks in advance
Hrishi

Re: Avoiding MFC CString

Albert Holguin12-Jul-11 5:47