I Love that New Syntax Smell : snippets

Windows Forms III - Dynamic Layout

arich — Thu, 05 Feb 2004 22:17:00 GMT

I'm not going to belabor my blog with yet another code explanation. I've converted the dynamic layout example (found here) from C# to C++. It isn't especially interesting, but it is good groundwork for later examples and projects.

Get the code! You can download this dynamic layout example here. As usual, both old and new syntax versions are included. And, as usual, if the old syntax version doesn't seem to compile, please let me know. The comments section on the sample download page has a note about avoiding a compiler warning.

CmdLiner - a break from Windows Forms

arich — Wed, 28 Jan 2004 22:55:00 GMT

This will be the third time I tried to start this post. Let's see if I get derailed yet again, or if I can actually finish it this time and get it up on the blog. To break from the monotony of Windows Forms, I'm uploading a snippet that wasn't originally intended to be a code sample. But, in my frantic grasp for content, it has become such.

What is CmdLiner? It's a tool I wrote for myself, to help parse command lines. (It will be used in larger projects, eventually.) I decided my command-line options loosely follow these rules:

switches are immediately preceded by a hyphen (-) a forward slash (/) or a back-slash (\).
non-switch arguments are anything that isn't in category 1, including the program name itself.
switches can contain arguments, which immediately follow the switch, and start with a colon (:) or equals (=). There can be multiple arguments, delimited by commas(,).

So, a valid command line might look like the following:
myprog /v -outfile:c:\temp.txt \r=200,13 infile.txt

How does it, ehm, how does it work? Consult the book of armaments! No, no. Actually, I compile it /LD, into a .NET assembly. Then, I can #using it from any program I want, to take advantage of its capabilities. I went back to the old C++ standard of defining the CmdLiner object in a .h file, and having the implementation in a .cpp file, rather than jumbling it all up in one source file. Being a C++ programmer at heart, that's really what makes the most sense to me.

Let's get into the code! I'll start with the .h file, and proceed from there. As always, my explanation is in Whidbey C++ syntax (old syntax code is also included in the sample, however), and the link to the sample download is way at the bottom.

//cmdliner.h - managed command-line argument parsing tool

using namespace System;

using namespace stdcli::language;

public ref class CmdLiner{

public:

CmdLiner(array<String^>^ args){ //requires the paramarray of main() to be passed in

loadargs(args);

}

Some typical using namespace declarations - the second being for the array<> template, and a constructor definition. .NET programs have their command-line options as an array of System::Strings. We simply take that information, and pass it along to the private loadargs function, which will actually perform the job of parsing the command line. (Most of the rest of the class is just methods to access that information in a meaningful way.)

CmdLiner(int argc, char **argv){

array<String^>^ args=gcnew array<String^>(argc);

for(int i=0; i<argc; i++){

args[i]=argv[i];

}

loadargs(args);

}

Here's a second constructor. It takes the traditional C++ command-line arguments, makes an array of Strings, fills it, and passes it along to loadargs.

int argc(){ return _args->Length; } //argument count (inlined)

bool switchOn(String^ sw); //is a particular switch thrown?

array<String^>^ switchArgs(String^ sw); //return any arguments for a switch /s:arg1,arg2

array<String^>^ nonswitchArgs(); //return all non-switch arguments

int nswc(); //number of non-switch arguments

String^ getarg(int index){ return _args[index]; }

String^ getdearg(int index){ return _deargs[index]; }

Most of these methods are used to access the already-parsed command line information. These are safe to call pretty much any time after the constructor runs. The switchOn method is probably the most useful, with switchArgs and nonswitchArgs also being useful. There's some reference in the inlined functions to private members, like _args. We'll get to those in a second. I think I chose some slightly confusing names. Were the sample not already uploaded (uploading a sample has an average 12-hour turnaround time), I might actually go fix them. The switchArgs method returns an array of the arguments for a particular switch (see rule 3 up at top), but nonswitchArgs returns an array containing all arguments that aren't switches (rule 2).

private:

array<String^>^ _args;

array<String^>^ _deargs;

String^ dearg(String^ arg); //removes /-\=: and anything following =:

void loadargs(array<String^>^ args);

int getSwIndex(String^ sw); //gets the array index of sw, -1 if not found

};

Here are those private members, and a few private methods. The arrays _args and _deargs store our parsed arguments. The _args array stores them, complete with slashes and all the option arguments, and _deargs has just the switch. (In the case of a non-switch argument, the _deargs entry contains nullptr.) Also, the loadargs method we've seen earlier, and dearg and getSwIndex, both of which are obvious, based on their comments.

Now, onto the meat. Let's get to the real point of this one - the implementation.

//cmdliner.cpp - requires cmdliner.h, build /LD

#include "cmdliner.h"

using namespace System;

using namespace stdcli::language;

#define STRARR(x) ((String^)x)->ToCharArray()

This is all old hat - we've seen all this before. (If you don't remember STRARR, go check out an old sample, loc.)

bool CmdLiner::switchOn(String^ sw){ //is a particular switch thrown?

if(getSwIndex(sw)>=0) return true;

else return false;

}

Here, we're determining if a switch the user requested has been thrown, and we use the private method getSwIndex, which returns -1 if the switch isn't found, and returns the index to the switch otherwise.

array<String^>^ CmdLiner::switchArgs(String^ sw){

//return any arguments for a switch /s:arg1,arg2 or -s=arg1,arg2

int index=getSwIndex(sw);

int argindex=0;

if(index>=0){

if(_args[index]->IndexOf(':')>=0) argindex=_args[index]->IndexOf(':');

else if (_args[index]->IndexOf('=')>=0) argindex=_args[index]->IndexOf('=');

else return nullptr;

String^ justargs=(_args[index]->Substring(argindex+1));

return justargs->Split( STRARR(",") );

}

return nullptr;

}

The switchArgs method returns the arguments for a switch. It returns an array of arguments because there could potentially be multiple arguments to any one switch. Basically, we first use the String::Substring method to get everything after the = or :, and then use String::Split to divide up the strings by the comma delimiter. Looking over this code, I see a flaw, where a user could break this method by specifying an argument that starts with an equals, but has a colon in it (like a path): /d=c:\windows\system32. Oops! Well, watch out for that bug. Or fix it, if you so desire. Typically, it only has negative effects when the path is not on the same drive as the program is being run on, since the bug basically has the effect of removing the drive specification, for paths, anyhow.

array<String^>^ CmdLiner::nonswitchArgs(){ //return all non-switch arguments in order

if(nswc()<=0) return nullptr;

array<String^>^ retarr = gcnew array<String^>(nswc());

int arrindex=0;

for(int i=0; i<argc(); i++)

if(!_deargs[i]) retarr[arrindex++]=safe_cast<String^>(_args[i]->Clone());

return retarr;

}

This method returns only the non-switch arguments. I do this by creating a new array of the right size (I figure that out using the nswc method), and then looping through all the arguments, checking _deargs to see if it's empty. If it is, we copy the corresponding _args entry into our temporary array. Since retarr contains only the non-switch arguments, it has to keep and increment a seperate index (arrindex) from the loop variant.

int CmdLiner::nswc(){ //number of non-switch arguments

int count=0;

for(int i=0; i<argc(); i++)

if(!_deargs[i]) count++;

return count;

}

Here's that nswc method. It basically just loops through _deargs, counting the number of blank entries. Pretty straightforward.

String^ CmdLiner::dearg(String^ arg){ //removes /-\=: and anything following =:

//only if it IS an argument (leads with a /-\)

if(arg[0]=='\\' || arg[0]=='/' || arg[0]=='-'){

arg=arg->Trim( STRARR("\\/-") );

return (arg->Split(STRARR(":=")))[0];

}

else return nullptr;

}

This method takes an individual argument, and strips off all the characters that don't represent the actual switch. If it isn't a switch, it returns nullptr.

void CmdLiner::loadargs(array<String^>^ args){

_args = safe_cast<array<String^>^>(args->Clone()); //get a copy of the args array

_deargs=gcnew array<String^>(argc());

for(int i=0; i<args->Length; i++) //clone the array, dearg'ed

_deargs[i]=dearg(_args[i]);

}

The loadargs method is the one called from the two constructors. Basically, it just fills the _args and the _deargs arrays, using the dearg method. I perform the argument stripping once, and for all the arguments up front, so I incur that cost once, rather than distributing it out among several calls (which could potentially be more costly, in the long run).

int CmdLiner::getSwIndex(String^ sw){ //gets the array index of sw, -1 if not found

for(int i=0; i<_deargs->Length; i++)

if(String::Compare(sw, _deargs[i], true)==0) return i;

return -1;

}

Finally, the getSwIndex function. This is the method I'm least proud of, because it is a simple iterative search, rather than something possibly more efficient. However, the array is sorted by argument order, rather than alphabetically. A more efficient search algorithm would probably need to have the array sorted somehow, and still remember the original order of the switches. It really turns the switchOn method into a O(n²) operation - but since the calls to switchOn are spread out, it isn't so bad.

Get the files! You can find them here. Please drop me a line if you try this out and find it useful, and especially if you find that the Managed Extensions version doesn't compile under VS.Net 2003. Stay tuned - a future sample that I'm working on will make use of CmdLiner.

Hello World from Windows Forms, MK II.

arich — Fri, 23 Jan 2004 03:13:00 GMT

Now that we've gotten our feet wet, it's time to try something a bit more complicated. We'll include a TextBox and a Button in this example, and also take a quick look at how we wire up events on actions like button clicks. I'm going to be skipping the explanation for code that we've already seen, and just concentrating on the new stuff. As always, scroll down for the sample download.

public ref class HelloWorldForm : public Form {

private:

Button ^button1;
TextBox ^textBox1;

Our HelloWorldForm now has two private members, button1 and textBox1. The UI elements they represent should be fairly obvious.

public:

HelloWorldForm() {

//allocate the private members

button1 = gcnew Button;

textBox1 = gcnew TextBox;

//Set up the Form

Text = "Hello Windows Forms World";

AutoScaleBaseSize = System::Drawing::Size(5, 13);

ClientSize = System::Drawing::Size(392, 117);

Here's the start of the default constructor, where all the basic setup for this form takes place. We gcnew our two private members, and we start setting up the form. I didn't go into this much last time, but what is happening here may not be totally obvious. Text, AutoScaleBaseSize, and the other members we'll see are members of HelloWorldForm's parent type, System::Windows::Forms::Form. To check out the various members of this type, head here.

Basically, we're setting up the form to have a client area size of 392x117 pixels. This is the default size, which is resizeable (based on whether or not you wish to allow this).

//Set the minimum form size to the client size + the height of the title bar

MinimumSize = System::Drawing::Size(392, (117 + SystemInformation::CaptionHeight));

//Set the default button on the Form

AcceptButton=button1;

It should be plainly obvious what the first line does. The reason we use the CaptionHeight property is that the height of the caption bar (where the program icon, maximize and close buttons, etc. are displayed) can change, depending especially on the font the user has set their default program title to. AcceptButton is the default button on a form that is pressed when the user hits the Enter key. (There's also a CancelButton, which is what is pressed when the user hits the Esc key.)

//Create the button

button1->Location = Point(256, 64);

button1->Size = System::Drawing::Size(120, 40);

button1->TabIndex = 2;

button1->Text = "Click Me!";

Here, we're simply populating our button1 with various useful attributes. The position for Location is based on the upper left-hand corner of the form (which is 0,0). In this case, our button's upper left-hand corner is 256 pixels right and 64 pixels down from that origin.

//Register the event handler

button1->Click += gcnew System::EventHandler(this, &HelloWorldForm::button1_Click);

This is probably the most interesting single line of code in this example. We're probably all aware that Windows is an event-based world. The program sits out there, and waits for user input - whether it be striking a key on the keyboard, or some form of mouse movement. So, we have to be able to wire up function calls to actions the user could perform. We call these actions events. System::Windows::Forms::Button::Click is one such event. (Actually, Click is an event that Button inherits from a common base class, System::Windows::Forms::Control.)

We can wire up a function to handle an event by using the += operator. This allows us to add multiple handlers to a single event (which can be very useful). We pass a this pointer and a pointer to the handler function to the EventHandler constructor, and add that temporary object to the Click event. Now, when the user clicks button1, the function button1_Click will be called! (The definition of this function is below.)

//Create the text box

textBox1->Text = "Hello Windows Forms World";

textBox1->TabIndex = 1;

textBox1->Size = System::Drawing::Size(360, 20);

textBox1->Location = Point(16, 24);

More property set-up, this time for our TextBox. The TabIndex property that you see here (and on button1) represents the order that the controls are focused on, with multiple presses of the Tab key. The focus starts on whatever control has TabIndex 1, and, with subsequent presses of Tab, will cycle through the different controls in order. When the last TabIndex is reached, we loop around to the first again.

//Add the controls to the form

Controls->Add(button1);

Controls->Add(textBox1);

}

Finally, we need to Add our two controls to HelloWorldForm's Controls. Up to this point, the controls have been merely classes that happened to be members of our form. When you hook them up by Adding them, they become visible, clickable objects inside the UI. This is important to remember, if you don't register your control, it simply won't be visible, and you'll be left wondering why.

protected:

void Dispose(bool disposing)

{

try {

MessageBox::Show("Disposed!");

} catch(Exception^ e) {}

Form::Dispose(disposing);

}

I wouldn't have shown you the Dispose function again, except that this time, I'm using MessageBox::Show to pop up a standard Windows dialog while I'm disposing the class, to demonstrate exactly when Dispose gets called. This is bad design, however, as you typically don't want anything in a Dispose function that doesn't need to be there.

private:

void button1_Click(Object^ sender, EventArgs^ evArgs) {

MessageBox::Show(String::Concat("Text is: '", textBox1->Text, "'"));

}

};

Here's button1_Click, the function that is wired up to our button's Click event. It also uses MessageBox::Show to pop up a Windows dialog, with the text of whatever is in our TextBox. We also close out our class here.

int main() {

Application::Run(gcnew HelloWorldForm);

return 0;

}

And, last but not least, our main function. Still not flashy, it does the same thing it did in our first example.

Whew, that was longer. Yes, it was, but it also did a whole lot more, and without too much additional code. Next time, we'll be looking at the power of Windows Forms dynamic layout.

Get the files. You can get the sample here. This contains two files, hwf2.cpp, and hwf2OS.cpp. Hwf2 is the complete code sample above, and hwf2OS.cpp is the Managed Extensions version of it. As always, if something doesn't compile properly, or you have questions, please post a comment.

Hello World from Windows Forms!

arich — Thu, 22 Jan 2004 00:39:00 GMT

It begins... This will be a new series of articles. I'll start with some ports of existing samples (from here), and move into some original material. I want to take a Managed C++ (and specifically a Whidbey C++) approach to Windows Forms, and investigate what exactly we can do with this powerful library. I've created a seperate post category (+RSS) for this special set of samples, in case you want to track this set of articles specially.

On to the first sample, the ever-traditional Hello, World. As always, the link for the sample is at the bottom.

#using <System.Windows.Forms.dll>

#using <System.dll>

#using <System.Drawing.dll>

using namespace System;
using namespace System::Windows::Forms;

We start by #using a few new dll's. System.Windows.Forms.dll contains most of the important forms classes, System.dll includes some important basic types, and System.Drawing.dll contains some additional important types. A few using namespace declarations will help cut down on typing.

public ref class SimpleHelloWorld : public Form {

public:

SimpleHelloWorld(){

Text = "Hello, World.";

}
};

Here, I've declared a new ref class, SimpleHelloWorld, inherited from the type System::Windows::Forms::Form. I override Form's default constructor with one of my own, that sets the Text property to, surprise, “Hello, World.”

int main(){

Application::Run(gcnew SimpleHelloWorld);

}

Here's my main function. I make a call to System::Windows::Forms::Application::Run, and pass it an instance of my SimpleHelloWorld class. The Application::Run function will block until the form passed to it is closed.

That's it? It is undoubtedly simpler than many Windows applications you've seen in the past. No HWNDs, no fancy CoCreateInstances, not even a WinMain! It looks just like a lot of other simple C++ programs you've seen in the past, except this one creates a real window. Yes, it may be a simplistic window with no features, but we're on our way.

Get the files. You can get the files here. This contains two files, hwf.cpp and hwfOS.cpp. Hwf.cpp is the code sample above, in Whidbey C++, and hwfOS.cpp is the Managed Extensions version of it. I don't have an install of VC.NET 2003 handy, so please post a comment if it doesn't compile or work properly.

loc - my own simple .NET version of the unix 'which' facility

arich — Thu, 15 Jan 2004 20:21:00 GMT

As is often the case, I wrote a small program to do something useful for myself. I have a (Win32) copy of the unix “which” utility, but I wanted something that would simultaneously search my path, include, and lib environment variables. What I came up with was loc, and it is a pretty simple, but pretty cool, example of what you can do with the .NET runtime.

I'm including both the old and new syntax versions of loc, as locOS.cpp and locNS.cpp. (Take a guess which is old syntax and which is new.) Really, the conversion from old to new in this case was really painless. I just had to fix the array syntax, and use handles instead of gc pointers. Enough small talk, let's get on with the code! As is my preference, I'll use the new syntax to describe the code. (Scroll to the very bottom of this post to get the code.)

using namespace System;

using namespace System::IO;
using namespace stdcli::language;

Some fairly straightforward using namespace declarations. I need System for general things (like String), System::IO for some of the file IO stuff I'm going to use, and stdcli::language for the CLI array.

#define STRARR(x) (((System::String^)x)->ToCharArray())

Here's an interesting macro. As is the case with most macros, it isn't necessary, its just a time-saving measure. Here's the rub: some of the .NET runtime functions (like String::Split) take, as a parameter, a managed array of System::Chars (wchar_ts). Sometimes, you want to pass a string literal to these functions, and we don't provide a standard conversion from a string literal to a managed array of System::Chars. However, we do provide a conversion to a String^, and the System::String object has a member function, String::ToCharArray, that will give me that elusive managed array. So, I create an unnamed temporary String object out of x (which is my string literal) and call ToCharArray. Though I only happen to use it once in this program, I could use it a whole lot more. (And I have, in other code.)

int envSearch(String^ file, String^ env);

int main(int argc, char**argv){

if(argc!=2){

Console::WriteLine("usage: loc <file>");

return 1;
}

A couple of things here. First, a pretty straightforward global function prototype. Second, my main function, with the standard argument list. Then, a simple check to make sure that the user specified one (and only one) file name. Remember, the name of the program always counts as a command-line argument - that's why I check for two arguments. I print the usage for my program, and return 1 if the user didn't specify a file name.

String ^f = argv[1];

int found=0;

//we want to search a number of ENVs - path, include, lib

found+=envSearch(f, "path");

found+=envSearch(f, "include");

found+=envSearch(f, "lib");

if(found) return 0;

else return 1;
}

Here's the rest of my main function. I copy the filename the user gave me into a System::String, and create an int, found, that is going to remember if I found the file I'm looking for across several calls of envSearch. Everything else is pretty straightforward. Let's look at the real guts of the program, contained in the envSearch function.

int envSearch(String^ file, String^ env){

int found=0;

array<String^>^ dirs = (Environment::GetEnvironmentVariable(env))->Split(STRARR(";"));

for(int i=0; i<dirs->Length; i++){

String^ tmpFn = String::Concat(dirs[i], "\\", file);

if (File::Exists(tmpFn)){

Console::WriteLine("{0} ({1})", tmpFn, env);

found++;

}

return found;

}

Looks like founds are running cheap today. This one has the same role, just remembering if I've actually found the file I'm looking for or not, so I can give the user a meaningful return code from my program.

I use a static method of the .NET runtime, Environment::GetEnvironmentVariable to, you guessed it, get the contents of an environment variable. Unfortunately, it comes across as a single System::String, semi-colon delimited, and I'd prefer a CLI array of Strings. So, I use the String::Split function (and my handy STRARR macro) to split that string, on-the-fly, into an array of Strings.

Then, I loop through that array. I create a temporary filename by concatenating the directory from the environment variable with a backslash (escaped with a second one), and the name of the file I'm looking for. Then, I use the .NET method File::Exists to see if the file I want exists at the location I created. If it does, I output it, along with the environment variable the path was contained in (in parentheses), and increment found. That's it!

Getting the files! Of course, what we're all interested in, is where to get the files. You can get them here. There are two files in this zip:

locOS.cpp - the loc program source, in Managed Extensions (Everett) syntax.

locNS.cpp - the loc program source, in Whidbey C++ syntax.

PtrToStringChars v2 remix

arich — Tue, 18 Nov 2003 05:29:00 GMT

A while back, in order to get some code to compile, I had to update PtrToStringChars (found in vcclr.h) to work in the new Whidbey C++.

In case anyone wants this, I've posted my implementation (and a small main() to drive it) here: p2sc.zip.

Keep in mind: this is my personal implementation, and not necessarily the same one that will be shipped with Whidbey. However, if you're looking for a solution, it should work for you.

Simple stack code

arich — Thu, 13 Nov 2003 01:37:00 GMT

We've got a code sample today, of a simple integer stack implemented using Whidbey C++. I'll implement it using three pieces of code:

stack.h - definition of the stack
stack.cpp - implementation of the stack
main.cpp - driver program that makes use of the stack

I compile the stack class into a DLL (stack.dll), which I then import into the main program with #using. The beauty of stack.dll is that it should be consumable by any .NET-targeted language: C#, VB.NET, even ASP.NET. In fact, to prove this, I've also included drv.cs, a C# source file which consumes stack.dll.

Another benefit of using DLLs: during development, I found a bug in my stack program. I edited stack.cpp, recompiled the DLL, and ran main.exe again. I didn't need to recompile main! :)

To compile:

stack.cpp as a DLL: cl /clr:newSyntax /LD stack.cpp
main.cpp: cl /clr:newSyntax main.cpp
drv.cs: csc drv.cs /r:stack.dll

Get the files! The code is available as a zip file: stack.zip.