Richard Grimes wrote:[color=blue]
>
wizofaus@hotmail.com wrote:[color=green]
> > I had to dig around to find and download toolkits that others had
> > written for this, then figure out how to manually plug them in (as
> > opposed to the MFC app wizard which takes all of 3 seconds to use!).[/color]
>
> Yup. There was talk at Microsoft 3 or 4 years ago of producing an
> application framework for Windows Forms, but it was dropped. I suspect
> the reason was Avalon, which has document features built in. I mean, how
> could Microsoft persuade people to move to Avalon if they could do that
> stuff in WinForms? Yes, call me cynical.[/color]
I've read some brief technical overviews of Avalon, but does it really
built-in support for everything MFC does for you automatically, no
coding required, including:
* Standard file menu commands (New, Open, Save, Save As)
* Automatic generation of Open file dialog with correct filters etc.
* Tracking document "modified flag", and automatically determining
whether document needs saving
* MRU file list
* Multiple views (windows) all sharing data from a single document
* Choice of handling menu time/toolbar commands at either the document
or view level, depending on what makes the most sense
* Correctly handling menu changes between document types (and the
application when no document is shown)
* Correctly updating the title bar to show the document name first,
followed by the application title
* Automatic registering of file type information in Explorer
* etc. etc.
Even though none of the above is one it's own particularly difficult to
do, and even though I've more than occasionally had to struggle against
MFC in order to customize the behaviour (e.g. correctly remembering the
last directory used for different Open|Save dialogs - instead of
Windows' insane behaviour of remembering it across seemingly all
dialogs in all instances of the application), whenever I've tried
writing a document-based application without MFC I've found myself
having to write the same tedious boilerplate code, which is easy to get
wrong.
[color=blue]
>[color=green]
> > terminated numbers, whereas C# won't have a bar of it. Everything has
> > to be converted explicitly (not necessarily a bad thing, but makes the[/color]
>
> Oh, it is a good thing, believe me :-)[/color]
I'm not so sure. I can't even remember the last time I was bitten by
automatic numeric type conversions. Occasionally it's been a problem
as far as choosing the correct overload or customer conversion operator
at compile time, but in my code I was reading values as doubles, then
multiplying by a scale factor, and using them as integers to pass to
the Windows GDI functions. I don't see why I should have to explicitly
cast them to int every time. I also tried using floats and then the
float versions of the GDI plus API but that was just as messy (there's
no System.Float for a start!).
[color=blue]
>[color=green]
> > a start, I really had to make sure it wouldn't throw exceptions,
> > because at least in the Debug version, this were horribly slow.[/color]
>
> There really shouldn't be any difference between throwing exceptions in
> Release and Debug. All the support for exceptions is there regardless of
> whether you use /debug or not. The framework library is a Release build,
> but it throws exceptions. Indeed, you *should* throw exceptions in
> preference to returning error values.[/color]
I wasn't returning error values - I literally didn't know whether some
lines from the input data contained numbers or not. So I tried parsing
them, and if they failed, I ignored them.
It wasn't an "exception" if they weren't numbers.
But worse, most of the numbers were immediately followed by
alphabetical characters (e.g. 100.0A). In this case, the "A" was the
correct terminator, but try telling System.Convert that.
[color=blue][color=green]
> > d) The really surprising part - the C# *debug* version ran miles
> > faster than the C++ optimized version! I'm actually 99% sure this is
> > because the C++ version ran off the standard Windows timer
> > (WM_TIMER), which severely limited the speed. For the C# version, I
> > just used whatever Timer component was supplied by .NET with a 1
> > millisecond interval, and obviously this was firing far more rapidly
> > than under the C++ version. Still, I was quite impressed here -
> > although the app was never really CPU bound in the application logic.[/color]
>
> I am not sure that this is the reason. Think about what is happening in
> your C# code. The compiler generates IL, and then at runtime this gets
> converted to x86 by the JIT compiler. Guess who wrote the JIT compiler?[/color]
Sure, but in this case, I know it was the timer. Taking the timer out
of the equation, the C++ version was slightly faster, but given most of
it's time was executing GDI calls, there's wasn't a big difference.
The C++ version was also definitely much faster loading the document
file in, for a start (this was the one part where any significant CPU
was needed).
