While it’s an absolute tragedy that C++ does not directly support compiled Xaml, you can use Xaml dynamically from a C++ Avalon app using
XamlReader::Load. Let me show you how to do that, using a simple example. You can create your Xaml file, either using a text editor or using a temporary dummy C# or VB project.
Now here’s the C++ code that will load this Xaml, show the window, and also hook events to the member controls. The code is mostly self-explanatory if you understand basic .NET event handling.
ref struct EventHelper
static void OnBtnClick(Object^ sender, RoutedEventArgs^ e)
Window^ mainwnd = Application::Current->MainWindow;
TextBox^ txtbox = (TextBox^)mainwnd->FindName("mTextBox");
mainwnd->Title = txtbox->Text;
Stream^ st = File::OpenRead(
Window^ mainwnd = (Window^)XamlReader::Load(st);
mainwnd->Height = 400;
mainwnd->Width = 600;
mainwnd->Title = "Dynamically load Xaml";
//FindName will find the element with the specified identifier
Button^ btn = (Button^)mainwnd->FindName("mButton");
btn->Click += gcnew RoutedEventHandler(&EventHelper::OnBtnClick);
return (gcnew Application())->Run(mainwnd);
This Avalon stuff is pretty powerful I can tell you. Expect more entries as I figure out more stuff :nerd:
This is my latest Code Project article, and it shows you how to use the Windows Forms 2.0
ToolStrip controls in your MFC applications to give them an Office 2003 look and feel. These Forms controls are pretty well written, and if you change the XP theme/style, they change accordingly, just like Word or Excel would!
9 times out of 10, when I select a class name or a keyword and hit F1, the Document Explorer shows me an “Information Not Found” page. But at the same time, the index on the left has selected the topic I am looking for, which means all I need to do is to double click on that topic and the expected page loads. So it’s truly mysterious to me why the Document Explorer says it cannot find the required information! Am I the only one who gets these sort of errors? Pretty damned annoying when it happens all the time!
I was working on an app that uses CCW to access a managed library. One of the methods in the library returns an
array<String^>^. The COM version of this method will have a
SAFEARRAY** as the
[out,retval] parameter. Not having a lot of COM experience, I was pretty surprised to find how little documentation there is on MSDN or any where else for that matter on using a
SAFEARRAY. All I wanted to do was to enumerate the returned array. Eventually it turned out to be pretty easy. For the interested few, here’s what you need to do.
SAFEARRAY* pSA= NULL;
long lbound = 0, ubound = 0;
SafeArrayGetLBound (pSA, 1, &lbound);
SafeArrayGetUBound (pSA, 1, &ubound);
BSTR* s = NULL;
SafeArrayAccessData(pSA, (void**) &s);
wcout << "XXXXXXXXXXXX" << endl;
for(long i=lbound; i<=ubound; i++)
wcout << "\t" << s[i] << endl;
The following code will not compile :-
You’ll get a compiler error (C2371) saying that you are redefining
WCHAR. The problem is that wabdefs.h defines
WCHAR as a
WORD, while winnt.h defines
WCHAR as a
wchar_t. In VC++ 2005, /Zc:wchar_t is on by default, which means that
wchar_t is a totally different type from
unsigned short, as older compilers would expect it to be. This is a definition clash and the bug is in winnt.h, and it’s amazing that the PSDK team didn’t pick this one. If you are an app developer, you can modify your local copy of winnt.h, but if you are a developer who works on a source code library, you are going to have some angry clients when you tell them that they need to edit their winnt.h to get the library to compile. This bug is a total pain in the ass and until the PSDK team fixes winnt.h, there’s no real workaround :grrr:
After a long gap, I’ve written another article for The Code Project.
The article is a simple introduction to using the
CWinFormsControl MFC class to put a Windows Forms control on an MFC dialog.
Every day, every single day, somebody asks on the Microsoft NGs and the Code Project forums whether she can use VC++ 2005 to write native applications that do not use the .NET Framework. It’s amazing how the confusing naming used by the previous versions, where VC++ 2002 was called VC++.NET 7 and VC++ 2003 was called VC++.NET 7.1, had a telling effect on the minds of people.
Anyway, to anyone who’s still in doubt, the answer is, yes, you can write purely native applications with VC++ 2005, and those can be Win32 API applications, MFC/ATL applications, WTL applications and just about anything native really. The Express edition does not include MFC and ATL, which means that you are restricted to creating Win32 API-only applications (other than the managed project options which you are not interested in).
I think the marketing folks at Redmond who work on marketing VC++ 2005 need to start a serious campaign in trying to put the message out that VC++ can create native applications and is not a .NET only tool like C# or VB.NET. Too much stress is put on portraying VC++ as a mixed-mode programming engine, that the fact that it can still be used as a native coding environment is often overlooked. Oh well, maybe they intended it that way. :hmmm: