By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,979 Members | 960 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,979 IT Pros & Developers. It's quick & easy.

HELP - ".Net" user interface under Internet Explorer.. what to do ?

P: n/a
Hello all,

Once windows mmi programming was very easy - vb forms.. nice & easy.
nowdays, our customers have became IE freaks !!!
So, my question is, what is the best way to develop mmi in the ".Net"
environment, over an intranet / lan environment.
the first alternative is "Asp.Net".. though Microsoft is trying to
push it very hard, to me the idea seems to be very wrong. I think
that client code should be seperated from server code. Mixing client &
server code (without even mentioning screen refreshe issues) does not
feel right to me and my co-workers.
The second alternative is pure html code (+xml islands). I dont like
this idea... developing html in the 21 century seems a bit retro and
difficult.
My last alternative is ".Net Winforms" under IE. does anoyone has
experience with this alternative? theoreticly it seems to be a perfect
idea..
is it?

Thanks in advance,
Eran Eldor
Nov 18 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
There is never a single right answer to every solution. The fundamental
choice is one of rich client vs. thin client.

To develop a .NET rich client, you use WinForms. However, this does require
that every one of your users has the .NET runtime installed on their
machine, which may be a barrier to using this technology. It can be embedded
in IE, or it can be a stand alone application. You get a richer experience
that can take advantage of the hardware running on the client, but you have
more stringent requirements before somebody can run the application.

To develop a .NET thin client, you use ASP.NET (WebForms). Here, the client
needs only have a browser to use your application. You are limited by what
DHTML provides, but there are no client requirements other than a browser.

As for your feelings on mixing code, ASP.NET actually strikes a good
balance. There is a separation of declarative UI code and code behind, and
you can furthermore separate out your business logic into separate classes,
or even into web services. If you have a need for screen refreshes at a
certain interval, however, you can't be guaranteed that, and you will need
to be creative, either by running some client side code (JavaScript) or
embedding a rich control (.NET WinForm control, ActiveX control, or Java
applet). Each has its drawbacks.

--
Chris Jackson
Software Engineer
Microsoft MVP - Windows Shell/UI
Windows XP Associate Expert
--
More people read the newsgroups than read my email.
Reply to the newsgroup for a faster response.
(Control-G using Outlook Express)
--

"nico1469" <er*****@hotmail.com> wrote in message
news:6c**************************@posting.google.c om...
Hello all,

Once windows mmi programming was very easy - vb forms.. nice & easy.
nowdays, our customers have became IE freaks !!!
So, my question is, what is the best way to develop mmi in the ".Net"
environment, over an intranet / lan environment.
the first alternative is "Asp.Net".. though Microsoft is trying to
push it very hard, to me the idea seems to be very wrong. I think
that client code should be seperated from server code. Mixing client &
server code (without even mentioning screen refreshe issues) does not
feel right to me and my co-workers.
The second alternative is pure html code (+xml islands). I dont like
this idea... developing html in the 21 century seems a bit retro and
difficult.
My last alternative is ".Net Winforms" under IE. does anoyone has
experience with this alternative? theoreticly it seems to be a perfect
idea..
is it?

Thanks in advance,
Eran Eldor

Nov 18 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.