Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / General / May 2006

Tip: Looking for answers? Try searching our database.

Why are .Net UIs slower than C++ or classic VB?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Jim Hubbard - 01 May 2006 09:59 GMT
I've noticed (for quite some time now) that .Net UIs are not as responsive
(see Franklin Covey's PlanPlus for Windows XP or Symantec's .Net Norton
Antivirus or even the .Net version of Paint done by Washington University vs
good old Paint UIs for examples).

They are also not as professional looking as the older applications and the
reaction times of the UIs is not professional looking at all.

Why do you think this is?  Is it bad programming or is there something else
going on here?
Cor Ligthert [MVP] - 01 May 2006 10:28 GMT
For those who want to answer this,

Maybe it is right to read this thread first.

http://groups.google.com/group/microsoft.public.dotnet.general/browse_frm/thread
/a7b4d6bfe03316f6/028eada042806d5a#028eada042806d5a


Cor
Jim Hubbard - 01 May 2006 11:23 GMT
Especially this one.....

http://groups.google.com/group/microsoft.public.dotnet.general/browse_frm/thread
/a7b4d6bfe03316f6/028eada042806d5a#028eada042806d5a


Jim

> For those who want to answer this,
>
[quoted text clipped - 3 lines]
>
> Cor
Jim Hubbard - 01 May 2006 12:22 GMT
Cor,

Perhaps you missed it the firat time, so here is a link for you.

http://groups.google.com/group/microsoft.public.dotnet.languages.vb/msg/cca0711d
1dc4e3d2?as_umsgid=KPo%25f.514$oW1.47@bignews1.bellsouth.net
)

If anything in the post is unclear, please let me know and I will try and
expain it further for you.

Thanks!
Jim

> For those who want to answer this,
>
[quoted text clipped - 3 lines]
>
> Cor
Barry Kelly - 01 May 2006 11:27 GMT
> I've noticed (for quite some time now) that .Net UIs are not as responsive
> (see Franklin Covey's PlanPlus for Windows XP or Symantec's .Net Norton
[quoted text clipped - 6 lines]
> Why do you think this is?  Is it bad programming or is there something else
> going on here?

I agree. I think (and hope) it's a lot to do with GDI+ not being
accelerated (and it probably will never be, as WPF approaches).
Something I've especially noticed is that resize logic for forms with
lots of nested containers is especially expensive. Very laggy resizing
of 16 or so nested containers of different kinds shouldn't slow a 3GHz
machine to a crawl, but it can and does!

-- Barry
Jim Hubbard - 01 May 2006 14:19 GMT
>> I've noticed (for quite some time now) that .Net UIs are not as
>> responsive
[quoted text clipped - 19 lines]
>
> -- Barry

The new Windows Presentation Foundation stuff looks much better than the UI
stuff we currently have for .Net.

Take a look at the demos for Windows Expression at
http://www.microsoft.com/products/expression/en/default.mspx.  In the demos,
the UIs look fast and smooth.  Not at all jerky or slow!

It's at the core of Vista's new look and is promised as an upgrade for XP
and 2003 Servers.

Just wish we had it now.....I'd hate to think I have to redo these apps all
over again a year (or so) from now.

Jim
Greg Young - 01 May 2006 16:08 GMT
> The new Windows Presentation Foundation stuff looks much better than the
> UI stuff we currently have for .Net.
>
> It's at the core of Vista's new look and is promised as an upgrade for XP
> and 2003 Servers.

You are right Jim!

> Just wish we had it now.....I'd hate to think I have to redo these apps
> all over again a year (or so) from now.

Thats why we tier apps right?

Cheers,

Greg

>>> I've noticed (for quite some time now) that .Net UIs are not as
>>> responsive
[quoted text clipped - 34 lines]
>
> Jim
JasonS - 01 May 2006 11:35 GMT
Well, I see two points of interest in this posting.

Firstly, some aspects of .NET display handling are slower, but I am more
then happy to occasionally sacrifice performance for the visual inheritance
that the .NET model gives me. No more days scouring sites for third-party
controls that have exactly the bizarre combinations of features, followed
by weeks of begging them to add the other features we require. Ah, blessed
relief.

The second point is that you seem to be trolling the newsgroups posting
inflammatory comments, for what reason I'm not sure, but I guess that you
feel any publicity is good publicity :)

I would suggest that anyone wanting to follow your line of argument use
Google to investigate the terabytes of newsgroup comments from VB6
developers between about 2002 and 2004, and leave this group free for
genuine questions and discussions.

Cheers,
 Jason

> I've noticed (for quite some time now) that .Net UIs are not as responsive
> (see Franklin Covey's PlanPlus for Windows XP or Symantec's .Net Norton
[quoted text clipped - 6 lines]
> Why do you think this is?  Is it bad programming or is there something else
> going on here?
Jim Hubbard - 01 May 2006 12:14 GMT
> Well, I see two points of interest in this posting.
>
[quoted text clipped - 5 lines]
> by weeks of begging them to add the other features we require. Ah, blessed
> relief.

That's a good point.  And, the object oriented nature certainly does allow
for easily extending the simple UI controls available for .Net.  But, I am
asking about the UI slowness that I have seen in professionally designed and
distributed .Net applications.  I want to avoid that slowness if possible.

> The second point is that you seem to be trolling the newsgroups posting
> inflammatory comments, for what reason I'm not sure, but I guess that you
> feel any publicity is good publicity :)

Hmmmm......  So, asking non-flattering questions is trolling?  AFAIK, these
applications could have been written poorly.  Hence the question.

If there are specific programming techniques that make the .Net apps seem
slow and kludgy, I want to know so that I can avoid those things.  So do you
know if it is due to programming technique or is it inherent in the .Net
framework?

There is actually an argument that can be made that states that .Net UIs
were made slower and more simplistic on purpose.  It can most certianly be
viewed as inflamatory by people not of an open mind to thoughts contrary to
thier own.  And, caring so deeply about your delicate nature, I would be
hesitant to post it here.

> I would suggest that anyone wanting to follow your line of argument use
> Google to investigate the terabytes of newsgroup comments from VB6
> developers between about 2002 and 2004, and leave this group free for
> genuine questions and discussions.

Questions about slow .Net UIs are not "genuine questions and discussions"?
Really?

Interesting...although I'm sure some of the more open-minded programmers
here would disagree.

Generally, I have found the members of this discussion group to be extremely
open-minded, willing to discuss .Net shortcomings (as well as its
accomplishments) and willing to help others avoid common programming errors
that may result in diminished performance in your .Net applications.

Jim
Patrice - 02 May 2006 14:39 GMT
So instead of starting a general discussion, IMO your best bet would be
rather to tell us what you have done that it slow so that one could attempt
to make suggestions to avoid this...

If not already done, you could start with UI code only and see how it
performs, post slow parts etc...
Signature

Patrice

>> Well, I see two points of interest in this posting.
>>
[quoted text clipped - 49 lines]
>
> Jim
Jim Hubbard - 02 May 2006 16:14 GMT
As I said in my post, there are several professional applications that you
can see this in.

I was (still am) wondering if this was due to sloppy programming on their
part or was it due to the slowness of the .Net UI.

If you have any ideas about this, I'd love to hear them.

> So instead of starting a general discussion, IMO your best bet would be
> rather to tell us what you have done that it slow so that one could
[quoted text clipped - 59 lines]
>>
>> Jim
Patrice - 03 May 2006 15:59 GMT
What do you want to do about those applications ?

You could try to decompile them if you wish but IMO it would be likely more
usefull to see this on your own real world example on which you have control
so it can be tested/changed. Else it will just raise IMO a general useless
discussion....

As .NET uses interop it is likely of outmost importance to minimize useless
calls (incidentally I'm coming accross an external application that refresh
4 times the same grid when it loads). Also you could try tricks such as
SuspendLayout/ResumeLayout or even hiding controls while you are intensively
updating them...

Signature

Patrice

> As I said in my post, there are several professional applications that you
> can see this in.
[quoted text clipped - 68 lines]
>>>
>>> Jim
Frans Bouma [C# MVP] - 03 May 2006 09:46 GMT
> So instead of starting a general discussion, IMO your best bet would
> be rather to tell us what you have done that it slow so that one
> could attempt to make suggestions to avoid this...
>
> If not already done, you could start with UI code only and see how it
> performs, post slow parts etc...

    .NET GUI's are dead slow, period. I have a form with several tabs and
grids. When I resize it, it whobbles and is in all aspects very slow. I
profiled the crap out of it, and every profiler comes up with core .NET
slowness. I can't do a thing about it to make it faster. When I check
out VB6 forms, they perform a lot faster, I can't lie about that, it's
true.

    That said, I also firmly think that winforms was a mistake. There are
simply too many issues with the winforms code. I hope WPF solves it,
though that's still far away and it will have its own list of
incompatibilities...

        FB

Signature

------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

Jim Hubbard - 04 May 2006 05:25 GMT
>> So instead of starting a general discussion, IMO your best bet would
>> be rather to tell us what you have done that it slow so that one
[quoted text clipped - 14 lines]
> though that's still far away and it will have its own list of
> incompatibilities...

And, it is certainly no shame that a company (ANY company - even Microsoft)
makes mistakes.  You always make mistakes.  Success is what is left after
you toss out all of the mistakes.  There's no shame in that.

The shame is when they cannot admit those mistakes (to themselves and their
customers), learn from them and move forward wiser and stronger than they
were before (with greater customer confidence and backing than before).

Even worse, they seem to simply try and hide one layer of mistakes with yet
another layer - instead of ripping out the weak parts and re-tooling the
layer.  The silliest thing is that Microsoft seems to try and hide it's
obvious mistakes from programmers no less.  How bizarre.....

Believe it or not, mistakes are how we grow.  When we learned to walk, we
tried to balance and fell on our bums many times before we got it right.
But, nobody ever ignored the fact that we fell down, they simply applauded
when we got back up.

Although it may not seem like it, I am a fan of Microsoft.  As a loyal fan,
I believe that I do Microsoft a dis-service by NOT calling them out on
things that are just plain wrong.  I want them to admit their mistakes - to
foster trust between the company and its clients and customers. I want it to
learn from its mistakes - because I want better tools and a better desktop.
And, I want a company that listens to its customers and follows what THEY
want....not what IT wants.

While I am chomping at the bit to try WPF, right now .Net reminds me of "The
11 Pound Pencil".  If you've never heard of "The 11 Pound Pencil" you should
read it at
http://www.mobilityguru.com/2006/03/05/who_designed_this_crap/ .

Jim
Barry Kelly - 01 May 2006 20:18 GMT
> Firstly, some aspects of .NET display handling are slower, but I am more
> then happy to occasionally sacrifice performance for the visual inheritance
> that the .NET model gives me.

I come from a Delphi background. I've had visual inheritance since about
1996, and the performance of my Delphi UIs (and I construct my .NET UIs
the much the same way as those Delphi UIs) is better.

However, I'm not really willing to give up the benefits of C# 2.0 to use
Delphi again, unless there's a compelling reason (such as a standalone
executable, higher performance graphics or native unmanaged code needed
for performance).

-- Barry
JasonS - 02 May 2006 13:43 GMT
> I come from a Delphi background. I've had visual inheritance since about
> 1996, and the performance of my Delphi UIs (and I construct my .NET UIs
[quoted text clipped - 4 lines]
> executable, higher performance graphics or native unmanaged code needed
> for performance).

I started using Delphi when it was first released, and I was delighted that
something came out that was object oriented with a nice GUI environment,
but Borland's original policy of charging 50 UK pounds for every technical
support question (and their very limited supplied manuals) meant there was
little likelihood of it being adopted at the banks I was working for,
particularly given that MS support at that time was free.

Borland's UI handling has always been very slick, probably largely due to
the fact most functions call the WinAPI directly without the overheads of
the intermediate functions performed by .NET such as locale specific
formatting, additional security features, visual 'theming' etc, which most
of us don't use but it does make sense to provide.

I wonder what the performance of the new WinFX will be :/

Cheers,
 Jason
CMM - 03 May 2006 01:46 GMT
I tend to agree with this post as well. Almost everything .NET does goes
through several layers, probably even a thunk or two (to convert say some
internal Long into a Win32 Int) until it finally reaches Win32... where of
course it goes through a couple of rings.

I wonder if there are ways for video card manufacturers to hook into .NET to
accelerate some things without waiting for the calls to reach Win32.... I
guess this is was Vista is suppossed to address.

Signature

-C. Moya
www.cmoya.com

>
>> I come from a Delphi background. I've had visual inheritance since about
[quoted text clipped - 24 lines]
> Cheers,
>  Jason
Mike Deakins - 01 May 2006 14:10 GMT
One of the reason might be GDI+ performance is too poor. Drawing a SXGA
bitmap using GDI+ takes 25ms on my computer.

Signature

Best Regards,
Mike J. Deakins

> I've noticed (for quite some time now) that .Net UIs are not as responsive
> (see Franklin Covey's PlanPlus for Windows XP or Symantec's .Net Norton
[quoted text clipped - 6 lines]
> Why do you think this is?  Is it bad programming or is there something
> else going on here?
Randolpho - 01 May 2006 16:08 GMT
I very rarely get poor responsiveness on .NET software. I wonder if
perhaps you're imagining things? If, however, there *is* poor
performance on a .NET application, I would blame one of two people:
either a) you are running .NET on a 486 sx 30 with 4 MB ram, or b) the
programmer(s) didn't understand how to write Windows.Forms. In the case
of Norton Antivirus, I'd say this is highly likely, as Norton has a
history of writing bloated crap that ruins your computer and is harder
to uninstall than most viruses.

Virii?
Frans Bouma [C# MVP] - 02 May 2006 10:03 GMT
> I've noticed (for quite some time now) that .Net UIs are not as
> responsive (see Franklin Covey's PlanPlus for Windows XP or
[quoted text clipped - 6 lines]
> Why do you think this is?  Is it bad programming or is there
> something else going on here?

    Winforms is synchronically, and Win32, which it is based on, is
asynchronically. So, say you want to disable a button in .NET, you set
button.Enabled to false, right? Well, under the hood, a message is send
to the button, and there's a delay when that's handled, the feedback
comes back that the message is handled and hte button is actually
disabled. This is a lot of overhead.

    For all the people who claim it's better in WPF: I'm sure it is, but
that's still a long time away and it doesn't help the people today.

        FB

Signature

------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

Jim Hubbard - 02 May 2006 16:25 GMT
>> I've noticed (for quite some time now) that .Net UIs are not as
>> responsive (see Franklin Covey's PlanPlus for Windows XP or
[quoted text clipped - 13 lines]
> comes back that the message is handled and hte button is actually
> disabled. This is a lot of overhead.

Yes it is.

It seems that Microsoft is simply adding layer upon layer to thier OS -
which would explain the OS bloat and ever-increasing system requirements.

.Net is an answer to an OS problem anyway.  The bufffer overflows that .Net
was meant to handle should be taken care of by the OS....not the programming
langauge and a runtime that lays on top of the OS.

Seems to me that Windows is long overdue for a complete rewrite from the
ground up.

Sure, this would mean breaking backwards compatability with some of the
older stuff, but they could include a personal copy of Virtual PC and allow
the user to run his/her old apps under the old OS while adopting the new,
slimmer, faster, more functional, Windows X and the new programming that it
allows.

>For all the people who claim it's better in WPF: I'm sure it is, but
> that's still a long time away and it doesn't help the people today.

It's been 5 (IMHO miserable) years with .Net.  Nothing really to show for
the effort outside the enterprise (where competition is limited and comtrols
are very tight).

.Net (IMHO) just isn't cutting it as the tool that the COMMUNITY uses to
expand the OS (and that's what you need to build a great OS).  It never
should have been written and forced upon us.  The problems with buffer
overflows should have been fixed in the OS - then it wouldn't matter what
tool you chose to write your code in.

But......whatever.......

Jim
AMDRIT - 02 May 2006 18:38 GMT
A can of worms was opened with this thread, I believe the core context it is
the next evolution in the C++ vs VB saga, and is continuing.  Coupled into
this thread is a reprised villainous assault towards another contributor
tiring the conversation out right and taking from heart of the conversation.

It is what it is, and it is about trade-offs.  C++ and VB are not dead,
gone, or otherwise non-employable.  Purists can still get the nominal
performance gains back simply be implementing those tools.  I do not believe
that performance is all that penalized in the .Net framework and have
several applications under my belt as proof of pudding.

That said, it is about trade-offs, and you trade raw performance with
sophisticated simplicity,   true connectedness, and commonality in form and
function.  Data binding in VB is a taboo thing, not all controls were data
aware, and inheriting them was complex at best and kludgy at worst.  API's
were needed for threading and message handling, while most of the samples
and documents were relegated to the world of C++.  The C++ world had to
write their event maps, use the APIs, decide on MFC, STL, ATL, SUV, ACLU and
a few other TLA's, still pointer management was rough, workflow continues to
elude even the veteran developer, and, ick, it's C++.

Enter the world of .Net.  Nearly everything you want is there out of the
box.  Developers really only have to concentrate on their workflow, business
logic and persistent data management.  Additionally, it quelled the qualms
and heated debates as to C++ and VB; they are now on an even playing field.
For raw power, performance, and interoperability; stick with the unmanaged
C++.  For ritual, mundane UI development any of the C++, C#, and VB
solutions will suffice in the implementation.  All three can talk to one
another without too much special consideration, a benefit and relief for
anyone that survived the COM/DLL HELL days.

The UI components provided out of the box are consistent and complete.
However; you are not tied to the implicit use of those controls including
the winforms.  While you have been provided the ability to have access to
all events, messages and awareness, you may and can create your own set of
UI components from the ground up inheriting right from System.Object.
Synchronous/Asynchronous, bah who cares, if you don't like red kool-aid, try
the purple.

You may be stuck with deploying the whole framework; however, you are not
tied to the whole framework.  And still, this conversation assumes that the
performance hit is such that it bothers the user.  ACT is an example of
something funky going on in the .Net world; however I think it has more to
do with data then the interface.

There are not a lot of commercial applications out there that I know of,
that employ .Net.  Those that are out there, I wonder about the teams that
employ them, were they trying to stick to the old ways and not taking full
advantage of the new features?  What about the code base, was a direct port
from earlier works or was it optimized and tweaked.  Did they clean up
disposable object, release resources?  Just because it is in commercial
release doesn't make it right, take a look at Windows ME's longevity and
acceptance.

.Net is the necessary evil in my world.  A development tool it not always
the most technically proficient bearer of results.  Why use .Net when Office
will work?  Why use .Net when windows scheduler will suffice?  Why drink Bud
Dry?  All decisions are influenced by external sources and not always the
right ones, why else would a normal human being pay thousands for a wiper
blade for a government aircraft?

In an experiment, I have created a VB application and a VB.Net application.
One form with one button each.  The button launches five new instances of
the form.  Using tick count, the times appear very similar.  What are
specifically seems slow and sluggish in your application?

I am running out of steam, so I will close with this.  Public ridicule
chastising public ridicule discredits your ability to ask serious questions
and weakens your perceived insight in future discussions, reiterating your
contempt was just petty, childish and low.

I don't know Cor, but I know of his work and involvement in the community.
Right or wrong, he and others are there to assist and help.  They do so, and
people are resolving their issues.  Yes, he may be doctrinated and advocates
his views in his responses, but doesn't a professor do the same when asked
to impart his knowledge?

When a co-worker annoys you, do you say so publicly?  When someone at Burger
King steps on your toes, twice, do you make a loud rebuke?  Professional
courtesy says you debate the points, agree to disagree, or just keep quite.
Common courtesy says you apologize for the terse, personal, and unwanted
comments.

>>> I've noticed (for quite some time now) that .Net UIs are not as
>>> responsive (see Franklin Covey's PlanPlus for Windows XP or
[quoted text clipped - 48 lines]
>
> Jim
CMM - 03 May 2006 00:57 GMT
Despite being a fan of .NET (from a programmer-- ease of development
standpoint) I tend to agree with almost everything you say. Windows is due
for a big rewrite a la MacOS X.... I doubt MS has the guts to do it.

Signature

-C. Moya
www.cmoya.com

>>> I've noticed (for quite some time now) that .Net UIs are not as
>>> responsive (see Franklin Covey's PlanPlus for Windows XP or
[quoted text clipped - 48 lines]
>
> Jim
Jim Hubbard - 03 May 2006 01:07 GMT
IF they ever did, it'd be interesting to see if they used .Net to write it.
I don't think they can.  You can't write an OS in entirely managed code -
can you?

I'd love to see them put buffer overflow protection in the OS and keep the
OOP (class designs and the core classes) of .Net while tossing the framework
(i.e. IL code) idea.  That should speed things up significantly.

Anyway, if they did a complete rewrite (slimming it down and speeding it up)
it would definitely be something worth paying to upgrade to.

> Despite being a fan of .NET (from a programmer-- ease of development
> standpoint) I tend to agree with almost everything you say. Windows is due
[quoted text clipped - 52 lines]
>>
>> Jim
CMM - 03 May 2006 01:39 GMT
Well I doubt the kernel would be .NET ;-) .... but the .NET Framework should
completely replace the Win32 API. And, I mean COMPLETELY.... not just a
layer over it (that eventually calls down into Win32 for everything) the way
its implemented now.

Signature

-C. Moya
www.cmoya.com

> IF they ever did, it'd be interesting to see if they used .Net to write
> it. I don't think they can.  You can't write an OS in entirely managed
[quoted text clipped - 64 lines]
>>>
>>> Jim
Cor Ligthert [MVP] - 03 May 2006 06:06 GMT
Carlos,

Almost from the first start of OS or DOS or Computer Management System
whatever names this kind of things have had (The first computers had no OS),
they have existed from layers. The reason for this is simple, by instance
hardware changes should not have to influence the overall system, which was
direct a problem after the first use of OS that did not exist from layers.

Therefore for me it is a very good approach that Net is one of those layers,
they would be crazy to change that.

Problem is maybe that the last 20 years a lot of people are sticked to
Microsoft Systems or other microprocessor driven systems and think that
those are the only ones and use the names of those and are not able to think
in wider use of computers.

Therefore in my opinion the Net should *not* replace the Win32 API, there
should come API's which have a high flexibility to interact with Net; Net
can than always be placed above those API's.

This cost of course time to see the results; you cannot get rid of Win32 in
some years. I never have had any attention to how WinFX is build; however I
assume that this normal way by creating a next generation OS will be the
case.

Just my thought,

Cor

> Well I doubt the kernel would be .NET ;-) .... but the .NET Framework
> should completely replace the Win32 API. And, I mean COMPLETELY.... not
[quoted text clipped - 71 lines]
>>>>
>>>> Jim
CMM - 03 May 2006 01:02 GMT
VB Classic made brilliant use of light-weight (not "real"... as in not
having hWnds) controls (The label, image, and shape controls) that were
painted by the VB Runtime and not handled by the OS. In .NET everything has
an underlying hWnd control underneath. These creates some "robustness" but
also introduces some bad performance... hWnd controls really are
"Windows".... they're created using the same API (CreateWindowEx) as "Forms"
and when an app has too many of them it quickly degrades in performance.

Signature

-C. Moya
www.cmoya.com

> I've noticed (for quite some time now) that .Net UIs are not as responsive
> (see Franklin Covey's PlanPlus for Windows XP or Symantec's .Net Norton
[quoted text clipped - 6 lines]
> Why do you think this is?  Is it bad programming or is there something
> else going on here?
Jim Hubbard - 03 May 2006 01:14 GMT
Perhaps that explains it.

One of the apps I noticed it most in was PlanPlus.  I was using a notebook
with a Celeron M processor and 1 GB RAM on XP Pro when I tested the trial
version.

With no other applications running (and no processes running rampant in the
background) whenever I clicked on a tab, you could almost watch the app
redraw every tab and button when it switched tabs.  Very ugly
implementation.  Looks unprofessional and slow.

Would I want to put my data into an app that looked ready to crash just
changing tabs?  I think not.

Franklin Covey prominently displays Agilix as a partner in the development
of PlanPlus.  Maybe they screwed this thing up.  Maybe they used some very
unprofessional controls.  Who knows......

I just want to make sure my apps look more professional than that.

I REALLY wish the WPF was available to use.  In the demos it looks
professional, very fast and responsive.  (Of course the PC it was running on
may have been a CRAY supercomputer.....but, it looked good.)

> VB Classic made brilliant use of light-weight (not "real"... as in not
> having hWnds) controls (The label, image, and shape controls) that were
[quoted text clipped - 15 lines]
>> Why do you think this is?  Is it bad programming or is there something
>> else going on here?
Frans Bouma [C# MVP] - 03 May 2006 09:48 GMT
> VB Classic made brilliant use of light-weight (not "real"... as in
> not having hWnds) controls (The label, image, and shape controls)
[quoted text clipped - 4 lines]
> API (CreateWindowEx) as "Forms" and when an app has too many of them
> it quickly degrades in performance.

    No, that's not the cause. Every win32/MFC app uses hWnd's under the
hood and they're very fast. The main cause is that the asynchronous api
of win32 is used in a synchronous way and that gives a lot of problems.
Not only in delays, but also in events which occur in the wrong order
etc.

        FB

Signature

------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.