Re: Getting management to move from green screen

Grigory, I'm not going to get into a point by point discussion because
it could go on for a long time. As just one example of why I believe
your advice is "dated" I will comment on your notes below.

I really really want to make clear that I believe you are very
knowledgable and talented, and you have obviously done many things
with many different technologies. I regret that I can't present
accurate information without making you feel insulted but my intent is
only to ensure that we do have accurate information here, and if we
have casualties along the way, so be it. I think you tend to learn
something once and then assume that it never changes - or perhaps you
don't continue to look for other solutions to ongoing issues. So when
you say here "this is the way it is", it shows you haven't been
keeping up with the craft. Trust me, I know how difficult it is to
both produce the code that is required to keep clients satisfied and
income coming in AND to keep on top of reading of the latest
technologies. But this is a necessary evil for our chosen trade.

GVP wrote:

Validation is very complex problem. Problem is INPUT FOCUS. Green
screen have fixed focus. GUI float.

It's easy to control focus with thick or thin GUI.

Only two way of validation are present.
1 By form (validation logic at client) and delayed validation at
server
2 By field (validation at server).

You can also validate groups of fields to minimize round-trips.
You can also do client-side field-level validation.
Complex and slow?

This is very complex and slow in GUI.

That depends on what you're doing and how. I think a world full of
Ajax developers would disagree with both Complex and with Slow.

Program should move focus after each validation.

That's easy with any language, even DHTML and scripting. I did a demo
of this with FlashCONNECT 8 years ago before the term AJAX was coined.

In any case (GUI), program don't know when it should validate field -
when field lost focus or when field receives it.

Sure it does, there are events for all conditions, again depending on
the technology you're using to develop the GUI. If you want more
control use a technology that supports it, but you can't claim such a
problem is general to all GUI.

As result, most of GUI applications uses delayed validation.

Incorrect. Again... Ajax. I don't use Ajax a lot yet but it's the
most commonly recognized answer to this particular point.

Next problem is .NET.

The discussion shouldn't digress from GUI vs greenscreen to
preferences about specific development/deployment stacks. These
topics are unrelated. But since we're here let's go with it.

Before I continue on Grigory's points...

I believe that rather than arguing about GUI vs greenscreen - a
discussion that people here should have had about 12 years ago and
this only exemplifies my point about old/invalid assertions here - we
should be discussing which tools to use, like the rest of the world.
Current options include Silverlight, Java, Adobe Flex, Rails, Gtk, and
various others that could be gratuitously mixed in here for thick or
thin clients. It's bad enough we're discussing whether or not GUI is
a good thing - it's a topic that sort of defines our dwindling market
space. But if you're going to use GUI, pick one and move forward -
don't sit on the fence for another decade.

I personally believe Silverlight is going to become a major GUI player
for all platforms. You guys can continue to tell me how dead wrong I
am about all this .NET stuff, but how bad is it when someone is
continually "wrong" in adopting technology that has lasted and
improved over 5 years and it's only getting better and more ubiquitous
across more platforms?


Now it is 3.5.
'Little' problem - applications works only with own framework. 1 with
1, 2 with 2 ... In this case at PC should be installed all versions
that need for applications. One version / 1-2 years.

We needed to load VBRUN3.DLL and similar components for Visual Basic
3, 4, 5, and 6. We need the right C++ runtime for deployment in
various environments and various releases. What about PHP4 vs PHP5?
Perl5 to the questionable Perl6? We need the right DirectX to support
new games, and this industry moves Very quickly. We need the right
dependency libs under Linux. We need the right JVM for Java. We need
the latest PDF reader to support the latest Acrobat encodings. Will
PostScript 6 documents work on printers that support PS5? Such
problems are industry-wide and not exclusive to .NET.

As always, new releases bring more features. If we want to make use
of the features we need the right components on all sides to support
it. This is not exclusive to GUI or .NET. What you don't mention
here is that many features of .NET v3 development can target the .NET
2 runtime. This is a developer option to relieve some of the burden
you describe. Do other environments have this option? Some do and
some don't.

The only burden of .NET Framework releases compared to other runtime
engines is the size.
..NET 1 = 23MB
..NET 2 = 22MB
..NET 3 = 2.8MB - it's just an optional add-on to .NET 2.
Various service packs are about 10MB

Please don't tell us end-users have a problem with disk space when we
can get a half-terabyte of disk for less than $100.

After next 5-10 years (will framework 9) all applications
will be unworkable

All releases of the .NET framework can run harmoniously with the
others. So you can have (and I do) .NET v1, 2, and 3 all on the same
system to run code targeted for any runtime. Similarly, many of us
have VB4, VB5, and VB6 runtimes. Interestingly, many of us don't have
VB4 runtimes for code that was written over a decade ago. The point
here is that we neither want nor need some of those old applications
because we want to use what's current and hopefully better. So while
we Can keep the runtimes for old components going back 5-10 years, we
could argue that in many cases we may not Want to. In any case, one
release of the .NET Framework does not preclude or require the use of
any other.

because MS will create new money cow (like as VB.NET after VB6
of framework for Vista SP3).

VB.NET costs nothing. The .NET Framework runtime costs nothing - all
releases can be freely downloaded. The .NET Framework SDK costs
nothing. As with Java and other stacks, applications can be created
and deployed without anyone making a single purchase.

I am as upset with Microsoft about their business practices as anyone
but the discussion of the moment does not relate to that. Nor does it
relate to Vista. GUI is not equal to .NET is not equal to Vista. And
for the record .NET is not equal to Microsoft if you wish to use Mono.


IMHO: .NET is death born idea in long terms. Each new OS or SP for OS
produces new .NET Framework.

That's completely inaccurate. The .NET Framework will run on all
platforms from Windows 98 through Vista.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
GreenScreen lives according MVDBMS.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

And the MVDBMS dies with greenscreen.

So, comments aside, my point here was to demonstrate that many of your
assertions on this topic are incorrect. I believe I have done so and
I won't continue to nit-pick with you.

If someone has questions about what is and is not possible with GUI or
any other separated client/server technologies, I recommend getting
your information from a variety of sources.

Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
Nebula R&D sells mv.NET and DesignBais worldwide,
and provides related development and training services


T
.

Relevant Pages

  • Re: Best book for learning MFC/VC 7.1 for developing rich GUI apps ?
    ... many people will ask why you're not considering starting from the .Net framework - which is where most of Microsoft's efforts are today. ... By the way the C++ compiler is the only one which can compile mixed binaries. ... all I need is to know how to create a GUI frontend for my libraries - I like .NET GUI capabilities but I don't like the fact that my binaries can be easily converted to source. ... C++/CLI code is still managed code and you have to deal with interoperability issues. ...
    (microsoft.public.dotnet.languages.vc)
  • Technologieberatung Dialoge (MFC/C#/HTML)
    ... eine Interface-Ebe zu HTML. ... Komplett in einer "Ebene" keine Interfaces zum Modul notwendig ... kein .NET Framework notwendig ... Nicht so komfortabel/einfach zu entwickeln (GUI) wie C# ...
    (microsoft.public.de.vc)
  • Re: Hobby .NET programming: C++ or C#?
    ... C# uses managed code it needs the NET Framework. ... Regarding .NET, I know that C++ doesn't require it, however I've basically decided already to use .NET regardless of my language choice. ... My motivation for this-- and do correct me if I'm misguided-- is that .NET provides Windows Forms which I understand is a easy way to hook into the Windows GUI facilities. ...
    (comp.programming)
  • Fatal error LNK1256: ALINK operation failed (8013110E)
    ... I'm creating a GUI using Windows Forms in C#. ... The problem I've encountered is when I try to build the DLL. ... and the version of .NET Framework I'm using? ...
    (microsoft.public.dotnet.framework)
  • LNK1256: ALINK operation failed
    ... I'm creating a GUI using Windows Forms in C#. ... The problem I've encountered is when I try to build the DLL. ... and the version of .NET Framework I'm using? ...
    (microsoft.public.dotnet.general)