KIS Systems, Inc - Contract Programming for Unix/Windows/Web in C++/C#/PHP/Qt/.NET and other technologies.

KIS Technoblog

Technical ruminations from our chief codemeister – Rick Berger

Archive for August, 2006

.NET ‘Validating’ event and ‘ErrorProvider’ class

Posted by admin on 29th August 2006

Found this little gem while looking to constrain textbox input to numeric.

It works by constructing an ErrorProvider instance in the container form, and then specifying and setting validation states during the ‘validating’ and ‘validated’ messages sent from the control. ErrorProvider is a generally available class that signals the error by flashing an icon next to the control with the offending input

It has some interesting points – ErrorProvider can be used in anything, not just textboxes. It locks focus and input to the control until you correct the input, and puts up a little blinking icon (which you can specify), to draw your attention to the offending input

Not quite the same as the Qt validator mechanism. I think Qt’s is better in that invalid input is suppressed by the supplied filter and won’t echo (it’s filtered out), however, it is very specific to textboxes.

In .NET, the invalid input is still echoed and the invalid state isn’t flagged until you move focus off the offending control. There may be a way around that (to provide a keystroke filtering behavior), but the standard implementation doesn’t appear to provide for it, that I can see.

Under the ErrorProvider topic in the MS documentation, there’s a lengthy example. You can reduce it to the following though (to restrict input in a textbox to numeric, for example):


  private Textbox inputTB;
  private ErrorProvider numberInputErrorProvider;
  private Regex regxNumeric;
              // declare these somewhere in your class...
              // the regular expression is used to qualify the validation.

  ...
  ...

  numberInputErrorProvider = new ErrorProvider();
              // create in the constructor of your *container* class

  regxNumeric = new Regex("^[0-9]*(\.[0-9]*){0,1}$");
              // ditto this - keeps it from having to be re-compiled
              // on every invocation.

  inputTB = new Textbox();
  inputTB.Validating += new
                  System.ComponentModel.CancelEventHandler(NumericTB_Validating);
  inputTB.Validated += new EventHandler(inlineFilterTB_Validated);
              // set up the textbox and add the event handlers.

  ...
  ...

  // gets called on focus loss
  //
  private void inputTB_Validating(object sender,
                                  System.ComponentModel.CancelEventArgs e)
  {
     TextBox tb = sender as TextBox;
     if (! regxNumeric.IsMatch(tb.Text))  // this is the test against the textbox text
     {
        e.Cancel = true;
        numberInputErrorProvider.SetError(tb, "Input must be numeric.");
                // this sets the error
     }
  }

  // Don't forget to add this!!  You need it to clear the error...
  //
  private void inputTB_Validated(object sender, EventArgs e)
  {
     TextBox tb = sender as TextBox;
     numberInputErrorProvider.SetError(tb, "");
  }

And, that’s pretty much all there is to it.

Posted in .NET, CSharp, Programming | No Comments »

On C#/.NET

Posted by admin on 28th August 2006

The current contract brings us into the C#/.NET world. Now that I’m up somewhat up to speed on it, I have a few first-blush thoughts:

The Language

First off, I can say I like the language. As in PHP and Java, the joy of being able to code and re-factor in almost “stream-of-consciousness” mode, without concern of headers and without long compile times is wonderful.

Syntactically, it is close enough to C++ that the transition is almost transparent, not unlike PHP and Java. Major differences are lack of pointers (except in ‘unsafe’ mode), and a larger number of access modifier keywords. Static vs. Dynamic is very well supported (although it would be nice to be able to declare a class ’static’, just for clarity.

What am I missing? For one, the inability to specify explicit ‘friends’ is a drawback. I can use (and am using) the ‘internal’ accessor keyword to restrict access to the current assembly, and that’s ok, but not completely sufficient.

This project is in 1.1: that means no ‘generic’ classes – the semi-equivalent of the C++ ‘template’ keyword. That is unfortunate. I’m having to write a few classes that vary only in type and are just screaming, “GENERIC”.

The ‘delegate’ type is equivalent to Qt’s signal/slot mechanism, although I don’t know if it’s as efficiently implemented, especially in 1.1. Syntactically, it is a bit clumsy, especially in the declarations, but adding and removing listeners is pure simplicity, using the ‘+=’ keyword (a far cry from the incredibly clumsy Visual Basic syntax to achieve the same thing, especially in the multi-cast scenario.)

Namespace support is very good and simple. I like that.

.NET

Another framework, another ‘App/Main Window/Supporting code/Dialog’ architecture, although the App class is a bit removed from the developer. You can access it, but not derive from it – you have to put working code elsewhere. Mostly I need it to clear messages Application.DoEvents(); before doing something heavy.

Thread support is good – named threads facilitate debugging. The UI thread is separate from all other threads and anything UI-ish must be done on the UI thread. In general, I don’t mind that – it does mean a bit more complication if you want to tie a UI piece, like a dialog, to a specific thread. I understand 2.0 has better support in this area, as well.

There’s a good, rich suite of controls and windows. They are more interchangeable than in the MFC construct, and dialogs are just a special type of window, rather than their own entity. It makes construction of dialog-based or other window-based applications much simpler.

Development Environment

I have some love-hate issues with the IDE: to begin, due to the verbosity and complexity of the language, it is almost indispensible. As big a fan of vi that I am, I wouldn’t want to try coding a lot of C# with it, at least not without a lot of ‘using’ keywords at the top. And, the language (again, like Java) encourages ‘onionskin’ layering of classes. With the proliferation of classes and interfaces, you’d be forever looking up names and members without the completion feature of the IDE.

Perhaps the most infuriating thing about the environment is the debugger – more often than not, when you get a crash, it can’t find the source. This is likely because the ‘real windows’ implementation is buried down in a system assembly, somewhere, and the debugger doesn’t see it. You resort to setting ever closer and closer breakpoints to discover the problem – almost, but not quite, as bad as print statements.

Summary

All in all, it’s a good environment and I like working in it. Of course, I have the normal “Microsoft Only” issues with it – I’d like to see a cross-platform implementation, but it will never come from Microsoft. There are open-source efforts, but they’re slow and will never catch up with the million-monkey-programmer army in Redmond.

Posted in .NET, CSharp, Programming | No Comments »

On Satellite Dishes

Posted by admin on 17th August 2006

I’ve had a DataStorm satellite dish system for quite some time now. In all, I’m pretty pleased with it (I’m posting this article from it, now), although it has had its trying moments.

The last came when my VAR (Optistreams) decided they didn’t want to be in the business, anymore. So, they dropped me. Then, I discovered my modems were old and I had to upgrade – no satellite would accept a commission on my old modems.

Well, fine. I needed an upgrade, anyway.

So, a new modem, a new VAR, and I’m talking again.

How Good Is It?

Well, it won’t replace your home land line. I find things tend to come down in bursts, and you have to get used to that. There is a built in latency that is governed by physics: The satellite is 25,000 miles out in space. A signal has to go up to the satellite, back to the ground station, and make the round trip back for any return data.

At the speed of light, that can take a quarter to a half a second. And, you can’t get past that barrier, with the physics we know, today.

Surprising, no?

Given the headache, though, it is great to be able to pop the dish up, anywhere, and have internet service. For me, it’s somewhat crucial, since I’m on the road a lot. I’ve had it as far north as Washington, and as far south as Mazatlan, and been able to put in productive work, wherever I happen to be.

Systems installed are around $4000 (mine was around $6500 – the cost of an early adopter…) You can find out more from the company: Motosat.com. Look for their DataStorm product.

rickb

Posted in internet, satellite, wireless | No Comments »

Preliminary Ramble

Posted by admin on 15th August 2006

Just to kick things off – a commentary on the development of programming languages and paradigms as I see them. If you want to find out more about KIS Systems, Inc, go here (or the main URL of this page.)

OO Languages Update
So, the darling language of the OO set back in the 70’s was SmallTalk. Pure. Elegant. Darling. And a damned nuisance to write anything real in. But, it has served as a sterling example of what an OO language should be like, if only we didn’t have to worry about real-world conditions.

After SmallTalk, there were attempts to turn everyone’s favorite structured language – C – into an OO language. C++ and Objective C were the primary outcomes. Objective C never really caught on outside of the Next folks – native compilers were hard to come by, and the dynamic binding aspects were still difficult for C programmers to get their heads around. C++ was more comprehensible to compiler writers – no dynamic binding like Java or Objective C. In the end, C++ compiles to mostly static objects. But, it interfaced with C seamlessly, was comprehensible to C programmers, and you could (and still can) write some wicked-fast code with it. So, it has become the de-facto standard development environment.

C++ is a bear to code and maintain. Separated header files, time consuming compiler optimizations, and direct access memory management make for fast code, but slow development and challenging debugging. Granted, there are tools and toolkits (I’ll be getting around to those) to make things easier.

However (thought many) there must be a better way.

The New OOs
And so, the birth of a plethora of OO languages to try to redo the SmallTalk paradigm, only more efficiently, and with more than a passing nod to C syntax.

We’ll ignore Perl and Visual Basic for this discussion – OO concepts have been grafted into the languages, but aren’t complete or enforced. The “new” OO languages widely used for large system or application development fall basically to Java or C#. Of course, there are devotees of other incarnations – PHP, Python, and Ruby, for instance, but they’re held by a narrow few.

What do we lose? Performance, of course – although there are devotees of all that claim near C++ performance, but never quite.

Actually, the stories from Java-land have been pretty horrific. Large-scaled systems that were coded in the holy-grail of “new paradigms” collapsed under their own weight, and have been abandoned and re-writted in C++ because they were simply unworkable in an interpreted language. And, too many practitioners tend to encourage expensive constructs, without regard to system resources.

Of course, things improve – Sun is working on the development environment, continually – and the hardware is getting faster and faster.

On the Microsoft end, we have C# and the CLR. A “better” Java, according to some. (Actually, Microsoft is quick to point out that code is never interpreted – JIT technology is used to produce machine-code right on the metal, when it’s needed.) Unfortunately, even though Microsoft is pushing it as a “standard”, it’s Microsoft’s standard, and it takes the rest of the world years to catch up with the million-man-army-of-programmers in Redmond. And, C# is tied intimately with .NET, which is decidedly not a standard, nor will it ever be, if MS has it’s way.

So, it’s (C#/.NET) a Microsoft only – which means Windows only. Which means narrow platform constraints, any way you cut it.

Personally, I don’t like getting locked into a single platform, even if it has the potential of being a superior technology. When C# and some ubiquitous cross-platform UI toolkit come together, I may ballyhoo it (and it may happen – see the mono project and the KDE Qyoto (mono-Qt) progress.)

Those are slow in coming. In the interim, I’m still sticking with C++ and Qt as the cross-platform development toolset of choice for any real (=large-scale) development projects.

Until the next great thing.

rickb

Posted in Programming, languages | No Comments »