Re: VB.net and ASP.Net Typed Datasets

See responses inline...


"Rick Vooys" <RickVooys@discussions.microsoft.com> wrote in message
news:4863365F-6A07-4CAB-BCB5-17F5D1C4DBC0@microsoft.com...
> Quick background, we are upgrading our old Access Application. We have
> upgraded the "backend" or data layer to SQL Server 2005. Currently we have
> the previous Access frontend linked via ODBC and are working on creating a
> new Frontend. The frontend only needs to be accessed via the company
> intranet, but in the future we would like to open up access for clients to
> view certain data.
>
> For these reasons we wish to use ASP.net, to have a Smart Client.
> Currently
> we have designed a DAL and BLL using typed datasets with the Dataset
> designer.
>
> But as we step through a section of our application, we are noticing VAST
> inadequacies with the web controls and the winform. I.E Combo boxes do not
> exist, the postbacks etc. We have tried some of the AJAX enabled controls
> but
> they do not take away all the issues.

The web forms controls must render to the client as standard client-side
code (HTML/CSS/JavaScript) - - there is no such thing as an HTML combobox
and thus, there is no combobox web form control either. This is not a .NET
deficciency, it is by design to allow for your client-side output to be
consumed by any web client. What "vast" inadequacies have you noticed? It
is possible that you just may not be aware of all the functionality of these
powerful controls. As for postbacks, why do you list this as a problem? If
you manage postbacks properly, you can greatly leverage your code.

> I have a couple questions, and I'm not sure if this the best forum for
> answers to these questions but any help, even which forum would be better
> suited for me is appreciated.
>
> 1. Can we use the typed Datasets we have created with the custom BLL with
> Vb.net. I have yet to see any examples?

Sure. Why not? A DataSet is a class and all .NET classes are designed to be
used in any .NET language (VB.NET being one of them). What language did you
use to build your BLL? Didn't you say it was written in VB.NET? If so, you
are already using DataSets with VB.NET, so I don't really follow your
question here.

As for examples, haven't you looked at the MSDN library that comes with
VS.NET? Simply look up DataSet and you'll see all kinds of samples using
VB.NET. Do a google search on VB.NET DataSet and you'll get a plethera of
results.

> Can someone point me in the direction
> of where the information to do this would be. In theory with a muti-tiered
> application I should be able to keep those layers completely independent
> and
> use either ASP.net or VB.net correct?

I think you are a bit confused here. ASP.NET is an architecture and VB.NET
is a language. It's not an either or scenario. You build web applications
(ASP.NET is the architecture of .NET web applications) in whatever .NET
language you choose to work in. Certainly VB.NET can be used to build
ASP.NET applications.

> 2. Is Microsoft going to take the Atlas/AJAX controls a step further? Or
> is
> there something we can use. I am sure the VB.net controls are much richer
> because they do not depend on the Windows Web form, but I cannot propose
> to
> roll out an application that makes data entry more difficult. Any ideas on
> how to streamline a ASP.net Web application to make it seem more desktop
> based? If I can keep the DAL and BLL the same, writing in VB.net and then
> in
> a year another rewrite is acceptable, but if we need to re-write those
> layers
> as well I will have to look at another plan of attack.

The DAL and BLL have nothing to do with controls since the user doesn't
interact directly with them. As stated, you can write your DAL and BLL in
whatever .NET language you like. If you feel the web forms controls lack
the interactivity you need, you can look at hosting a windows form from a
web page.

http://www.google.com/search?q=wind...ie=utf8&oe=utf8

>
> Thanks ahead of time.
>

Hi Rick,

Inline...

"Rick Vooys" <RickVooys@discussions.microsoft.com> wrote in message
news:98AC2FE4-D6E6-4604-A263-67DF9CC18A12@microsoft.com...
> Much thanks Scott, just to clarify some points the replys are inline.
>
> "Scott M." wrote:
>
>> See responses inline...
>>
>>
>> "Rick Vooys" <RickVooys@discussions.microsoft.com> wrote in message
>> news:4863365F-6A07-4CAB-BCB5-17F5D1C4DBC0@microsoft.com...
>> > Quick background, we are upgrading our old Access Application. We have
>> > upgraded the "backend" or data layer to SQL Server 2005. Currently we
>> > have
>> > the previous Access frontend linked via ODBC and are working on
>> > creating a
>> > new Frontend. The frontend only needs to be accessed via the company
>> > intranet, but in the future we would like to open up access for clients
>> > to
>> > view certain data.
>> >
>> > For these reasons we wish to use ASP.net, to have a Smart Client.
>> > Currently
>> > we have designed a DAL and BLL using typed datasets with the Dataset
>> > designer.
>> >
>> > But as we step through a section of our application, we are noticing
>> > VAST
>> > inadequacies with the web controls and the winform. I.E Combo boxes do
>> > not
>> > exist, the postbacks etc. We have tried some of the AJAX enabled
>> > controls
>> > but
>> > they do not take away all the issues.
>>
>> The web forms controls must render to the client as standard client-side
>> code (HTML/CSS/JavaScript) - - there is no such thing as an HTML combobox
>> and thus, there is no combobox web form control either. This is not a
>> .NET
>> deficciency, it is by design to allow for your client-side output to be
>> consumed by any web client. What "vast" inadequacies have you noticed?
>> It
>> is possible that you just may not be aware of all the functionality of
>> these
>> powerful controls. As for postbacks, why do you list this as a problem?
>> If
>> you manage postbacks properly, you can greatly leverage your code.
>
> I guess in my ignorance, I am not looking into the tools close enough. I'm
> sure there is a way to address each of my issues (only one field in the
> drop
> down, no autocomplete, etc).

Autocomplete is a feature of the browser, not your application. If the user
doesn't have it turned on, no control will give you this feature. .NET is
not limited in any way when it comes to controls, it's just that in a web
based application (ASP.NET) you don't know what client (browser) the user
will have and so you make sure that you only send the client standard code
(HTML/CSS?JavaScript). This is the reason that web pages tend to have
different data entry controls than in a desktop application (for example, no
combobox web forms control). Again, this is not a .NET issue - it's how you
make web applications in any development platform.

> I guess what I was looking for is an answer to
> this question. Is ASP.net a good architecture for a Order/Data Entry
> system?

Absolutely! As long as you rember my most previous comment above. I can't
imagine anything your clients would want that can't be achieved with
ASP.NET. You just go about things in a web application a bit differently
than you do in a client application.

> It just seems as we are building our "demo" we lose alot of the as you
> call
> it below, interactivity. I'm sure with more practice we can find
> workarounds
> and still gain the benifets of a web application.

Absolutely again! For example, we don't have comboboxes in web
applications, but you can certainly place a textbox above a dropdown list
and with a little JavaScript combine the two controls so that the user gets
the features of a combobox.

>> > I have a couple questions, and I'm not sure if this the best forum for
>> > answers to these questions but any help, even which forum would be
>> > better
>> > suited for me is appreciated.
>> >
>> > 1. Can we use the typed Datasets we have created with the custom BLL
>> > with
>> > Vb.net. I have yet to see any examples?
>>
>> Sure. Why not? A DataSet is a class and all .NET classes are designed to
>> be
>> used in any .NET language (VB.NET being one of them). What language did
>> you
>> use to build your BLL? Didn't you say it was written in VB.NET? If so,
>> you
>> are already using DataSets with VB.NET, so I don't really follow your
>> question here.
>>
>> As for examples, haven't you looked at the MSDN library that comes with
>> VS.NET? Simply look up DataSet and you'll see all kinds of samples using
>> VB.NET. Do a google search on VB.NET DataSet and you'll get a plethera
>> of
>> results.
>>
>
> When I google this I get typed datasets being used in a web application
> with
> either VB.net or C#. I am trying to use a Typed Dataset we created in this
> manner and import it into a Desktop Application written in VB.net. There
> seems to be some issues with the syntax, during the typed dataset init. it
> says the configuration manager is not a member of the configuration
> collection. Error # BC30456.

This sounds like a simple reference/importing issue. Are you saying the
DataSet was created in an ASP.NET project and you are now trying to use it
in a windows forms project?

>
>> > Can someone point me in the direction
>> > of where the information to do this would be. In theory with a
>> > muti-tiered
>> > application I should be able to keep those layers completely
>> > independent
>> > and
>> > use either ASP.net or VB.net correct?
>>
>> I think you are a bit confused here. ASP.NET is an architecture and
>> VB.NET
>> is a language. It's not an either or scenario. You build web
>> applications
>> (ASP.NET is the architecture of .NET web applications) in whatever .NET
>> language you choose to work in. Certainly VB.NET can be used to build
>> ASP.NET applications.
>
> I am a bit confused here. I understand with ASP.net you can do the
> programming in C# or VB.net and probably many more languages. What would
> you
> call it when you create the presentation layer and distributatble
> application
> in VB.net?

In ASP.NET there is no distributable anything - - all the processing takes
place on your server. Clients use their browsers to connect to your server,
your server processes the request and sends the client back a result. All
the client has to do is be able to understand what is being sent to it,
which is why ASP.NET applications produce HTML, CSS and/or JavaScript - -
these are all standard languages that all browsers understand.

> That is what I am trying to compare. I guess it would be a web
> application vs desktop application?

Sounds like it. But, understand that whichever you go with, the language is
irrelevant, so you might want to drop "VB.NET" from your analysis as this
isn't going to make a difference. "ASP.NET" means web-based application
architecture (where the program is run on the server). This can be written
in any of the .NET languages. A "Windows Forms" application is one that is
distributed (installed) on each client machine that wants to run it (like MS
Office). These applications can also be written in any of the .NET
languages.

In general, web-based applications are the better approach. Here are some
pro's and con's:

Web-Based (ASP.NET)
Pro's
1. Server-side code processing, so you can program in the
language/architecture of your choice.
2. Client is only required to have a browser (thin-client).
3. No software installs, updates and patches for the client to install.
4. Application scalability with no client impact.

Con's
1. Requires a robust server setup to handle expected volume.
2. Requires security measures be in place and monitored.
3. Can consume large amounts of bandwith.
4. Response time for the client is slower than a desktop application.

Hope this helps.


-Scott


>
>>
>> > 2. Is Microsoft going to take the Atlas/AJAX controls a step further?
>> > Or
>> > is
>> > there something we can use. I am sure the VB.net controls are much
>> > richer
>> > because they do not depend on the Windows Web form, but I cannot
>> > propose
>> > to
>> > roll out an application that makes data entry more difficult. Any ideas
>> > on
>> > how to streamline a ASP.net Web application to make it seem more
>> > desktop
>> > based? If I can keep the DAL and BLL the same, writing in VB.net and
>> > then
>> > in
>> > a year another rewrite is acceptable, but if we need to re-write those
>> > layers
>> > as well I will have to look at another plan of attack.
>>
>> The DAL and BLL have nothing to do with controls since the user doesn't
>> interact directly with them. As stated, you can write your DAL and BLL
>> in
>> whatever .NET language you like. If you feel the web forms controls lack
>> the interactivity you need, you can look at hosting a windows form from a
>> web page.
>>
>> http://www.google.com/search?q=wind...ie=utf8&oe=utf8
>>
>> >
>> > Thanks ahead of time.
>> >
>>
>>
>>

Another con of a web-based application is the UI can not
be as robust as it can be if you build the app with Windows
Forms -- you don't have as much control.

Robin S.
------------------------------------
"Scott M." <s-mar@nospam.nospam> wrote in message
news:%23JFXSJuLHHA.1248@TK2MSFTNGP02.phx.gbl...
> Hi Rick,
>
> Inline...
>
> "Rick Vooys" <RickVooys@discussions.microsoft.com> wrote in message
> news:98AC2FE4-D6E6-4604-A263-67DF9CC18A12@microsoft.com...
>> Much thanks Scott, just to clarify some points the replys are inline.
>>
>> "Scott M." wrote:
>>
>>> See responses inline...
>>>
>>>
>>> "Rick Vooys" <RickVooys@discussions.microsoft.com> wrote in message
>>> news:4863365F-6A07-4CAB-BCB5-17F5D1C4DBC0@microsoft.com...
>>> > Quick background, we are upgrading our old Access Application. We
>>> > have
>>> > upgraded the "backend" or data layer to SQL Server 2005. Currently
>>> > we have
>>> > the previous Access frontend linked via ODBC and are working on
>>> > creating a
>>> > new Frontend. The frontend only needs to be accessed via the
>>> > company
>>> > intranet, but in the future we would like to open up access for
>>> > clients to
>>> > view certain data.
>>> >
>>> > For these reasons we wish to use ASP.net, to have a Smart Client.
>>> > Currently
>>> > we have designed a DAL and BLL using typed datasets with the
>>> > Dataset
>>> > designer.
>>> >
>>> > But as we step through a section of our application, we are
>>> > noticing VAST
>>> > inadequacies with the web controls and the winform. I.E Combo
>>> > boxes do not
>>> > exist, the postbacks etc. We have tried some of the AJAX enabled
>>> > controls
>>> > but
>>> > they do not take away all the issues.
>>>
>>> The web forms controls must render to the client as standard
>>> client-side
>>> code (HTML/CSS/JavaScript) - - there is no such thing as an HTML
>>> combobox
>>> and thus, there is no combobox web form control either. This is not
>>> a .NET
>>> deficciency, it is by design to allow for your client-side output to
>>> be
>>> consumed by any web client. What "vast" inadequacies have you
>>> noticed? It
>>> is possible that you just may not be aware of all the functionality
>>> of these
>>> powerful controls. As for postbacks, why do you list this as a
>>> problem? If
>>> you manage postbacks properly, you can greatly leverage your code.
>>
>> I guess in my ignorance, I am not looking into the tools close
>> enough. I'm
>> sure there is a way to address each of my issues (only one field in
>> the drop
>> down, no autocomplete, etc).
>
> Autocomplete is a feature of the browser, not your application. If
> the user doesn't have it turned on, no control will give you this
> feature. .NET is not limited in any way when it comes to controls,
> it's just that in a web based application (ASP.NET) you don't know
> what client (browser) the user will have and so you make sure that you
> only send the client standard code (HTML/CSS?JavaScript). This is the
> reason that web pages tend to have different data entry controls than
> in a desktop application (for example, no combobox web forms control).
> Again, this is not a .NET issue - it's how you make web applications
> in any development platform.
>
>> I guess what I was looking for is an answer to
>> this question. Is ASP.net a good architecture for a Order/Data Entry
>> system?
>
> Absolutely! As long as you rember my most previous comment above. I
> can't imagine anything your clients would want that can't be achieved
> with ASP.NET. You just go about things in a web application a bit
> differently than you do in a client application.
>
>> It just seems as we are building our "demo" we lose alot of the as
>> you call
>> it below, interactivity. I'm sure with more practice we can find
>> workarounds
>> and still gain the benifets of a web application.
>
> Absolutely again! For example, we don't have comboboxes in web
> applications, but you can certainly place a textbox above a dropdown
> list and with a little JavaScript combine the two controls so that the
> user gets the features of a combobox.
>
>>> > I have a couple questions, and I'm not sure if this the best forum
>>> > for
>>> > answers to these questions but any help, even which forum would be
>>> > better
>>> > suited for me is appreciated.
>>> >
>>> > 1. Can we use the typed Datasets we have created with the custom
>>> > BLL with
>>> > Vb.net. I have yet to see any examples?
>>>
>>> Sure. Why not? A DataSet is a class and all .NET classes are
>>> designed to be
>>> used in any .NET language (VB.NET being one of them). What language
>>> did you
>>> use to build your BLL? Didn't you say it was written in VB.NET? If
>>> so, you
>>> are already using DataSets with VB.NET, so I don't really follow
>>> your
>>> question here.
>>>
>>> As for examples, haven't you looked at the MSDN library that comes
>>> with
>>> VS.NET? Simply look up DataSet and you'll see all kinds of samples
>>> using
>>> VB.NET. Do a google search on VB.NET DataSet and you'll get a
>>> plethera of
>>> results.
>>>
>>
>> When I google this I get typed datasets being used in a web
>> application with
>> either VB.net or C#. I am trying to use a Typed Dataset we created in
>> this
>> manner and import it into a Desktop Application written in VB.net.
>> There
>> seems to be some issues with the syntax, during the typed dataset
>> init. it
>> says the configuration manager is not a member of the configuration
>> collection. Error # BC30456.
>
> This sounds like a simple reference/importing issue. Are you saying
> the DataSet was created in an ASP.NET project and you are now trying
> to use it in a windows forms project?
>
>>
>>> > Can someone point me in the direction
>>> > of where the information to do this would be. In theory with a
>>> > muti-tiered
>>> > application I should be able to keep those layers completely
>>> > independent
>>> > and
>>> > use either ASP.net or VB.net correct?
>>>
>>> I think you are a bit confused here. ASP.NET is an architecture and
>>> VB.NET
>>> is a language. It's not an either or scenario. You build web
>>> applications
>>> (ASP.NET is the architecture of .NET web applications) in whatever
>>> .NET
>>> language you choose to work in. Certainly VB.NET can be used to
>>> build
>>> ASP.NET applications.
>>
>> I am a bit confused here. I understand with ASP.net you can do the
>> programming in C# or VB.net and probably many more languages. What
>> would you
>> call it when you create the presentation layer and distributatble
>> application
>> in VB.net?
>
> In ASP.NET there is no distributable anything - - all the processing
> takes place on your server. Clients use their browsers to connect to
> your server, your server processes the request and sends the client
> back a result. All the client has to do is be able to understand what
> is being sent to it, which is why ASP.NET applications produce HTML,
> CSS and/or JavaScript - - these are all standard languages that all
> browsers understand.
>
>> That is what I am trying to compare. I guess it would be a web
>> application vs desktop application?
>
> Sounds like it. But, understand that whichever you go with, the
> language is irrelevant, so you might want to drop "VB.NET" from your
> analysis as this isn't going to make a difference. "ASP.NET" means
> web-based application architecture (where the program is run on the
> server). This can be written in any of the .NET languages. A
> "Windows Forms" application is one that is distributed (installed) on
> each client machine that wants to run it (like MS Office). These
> applications can also be written in any of the .NET languages.
>
> In general, web-based applications are the better approach. Here are
> some pro's and con's:
>
> Web-Based (ASP.NET)
> Pro's
> 1. Server-side code processing, so you can program in the
> language/architecture of your choice.
> 2. Client is only required to have a browser (thin-client).
> 3. No software installs, updates and patches for the client to
> install.
> 4. Application scalability with no client impact.
>
> Con's
> 1. Requires a robust server setup to handle expected volume.
> 2. Requires security measures be in place and monitored.
> 3. Can consume large amounts of bandwith.
> 4. Response time for the client is slower than a desktop application.
>
> Hope this helps.
>
>
> -Scott
>
>
>>
>>>
>>> > 2. Is Microsoft going to take the Atlas/AJAX controls a step
>>> > further? Or
>>> > is
>>> > there something we can use. I am sure the VB.net controls are much
>>> > richer
>>> > because they do not depend on the Windows Web form, but I cannot
>>> > propose
>>> > to
>>> > roll out an application that makes data entry more difficult. Any
>>> > ideas on
>>> > how to streamline a ASP.net Web application to make it seem more
>>> > desktop
>>> > based? If I can keep the DAL and BLL the same, writing in VB.net
>>> > and then
>>> > in
>>> > a year another rewrite is acceptable, but if we need to re-write
>>> > those
>>> > layers
>>> > as well I will have to look at another plan of attack.
>>>
>>> The DAL and BLL have nothing to do with controls since the user
>>> doesn't
>>> interact directly with them. As stated, you can write your DAL and
>>> BLL in
>>> whatever .NET language you like. If you feel the web forms controls
>>> lack
>>> the interactivity you need, you can look at hosting a windows form
>>> from a
>>> web page.
>>>
>>> http://www.google.com/search?q=wind...ie=utf8&oe=utf8
>>>
>>> >
>>> > Thanks ahead of time.
>>> >
>>>
>>>
>>>
>
>

True (and that has really been the point of this thread), but as I mentioned
in my earlier post, you can host Windows Forms via an ASP.NET web page.


"RobinS" <RobinS@NoSpam.yah.none> wrote in message
news:5L6dnc5mCslggwbYnZ2dnUVZ_oipnZ2d@comcast.com...
> Another con of a web-based application is the UI can not
> be as robust as it can be if you build the app with Windows
> Forms -- you don't have as much control.
>
> Robin S.
> ------------------------------------
> "Scott M." <s-mar@nospam.nospam> wrote in message
> news:%23JFXSJuLHHA.1248@TK2MSFTNGP02.phx.gbl...
>> Hi Rick,
>>
>> Inline...
>>
>> "Rick Vooys" <RickVooys@discussions.microsoft.com> wrote in message
>> news:98AC2FE4-D6E6-4604-A263-67DF9CC18A12@microsoft.com...
>>> Much thanks Scott, just to clarify some points the replys are inline.
>>>
>>> "Scott M." wrote:
>>>
>>>> See responses inline...
>>>>
>>>>
>>>> "Rick Vooys" <RickVooys@discussions.microsoft.com> wrote in message
>>>> news:4863365F-6A07-4CAB-BCB5-17F5D1C4DBC0@microsoft.com...
>>>> > Quick background, we are upgrading our old Access Application. We
>>>> > have
>>>> > upgraded the "backend" or data layer to SQL Server 2005. Currently we
>>>> > have
>>>> > the previous Access frontend linked via ODBC and are working on
>>>> > creating a
>>>> > new Frontend. The frontend only needs to be accessed via the company
>>>> > intranet, but in the future we would like to open up access for
>>>> > clients to
>>>> > view certain data.
>>>> >
>>>> > For these reasons we wish to use ASP.net, to have a Smart Client.
>>>> > Currently
>>>> > we have designed a DAL and BLL using typed datasets with the Dataset
>>>> > designer.
>>>> >
>>>> > But as we step through a section of our application, we are noticing
>>>> > VAST
>>>> > inadequacies with the web controls and the winform. I.E Combo boxes
>>>> > do not
>>>> > exist, the postbacks etc. We have tried some of the AJAX enabled
>>>> > controls
>>>> > but
>>>> > they do not take away all the issues.
>>>>
>>>> The web forms controls must render to the client as standard
>>>> client-side
>>>> code (HTML/CSS/JavaScript) - - there is no such thing as an HTML
>>>> combobox
>>>> and thus, there is no combobox web form control either. This is not a
>>>> .NET
>>>> deficciency, it is by design to allow for your client-side output to be
>>>> consumed by any web client. What "vast" inadequacies have you noticed?
>>>> It
>>>> is possible that you just may not be aware of all the functionality of
>>>> these
>>>> powerful controls. As for postbacks, why do you list this as a
>>>> problem? If
>>>> you manage postbacks properly, you can greatly leverage your code.
>>>
>>> I guess in my ignorance, I am not looking into the tools close enough.
>>> I'm
>>> sure there is a way to address each of my issues (only one field in the
>>> drop
>>> down, no autocomplete, etc).
>>
>> Autocomplete is a feature of the browser, not your application. If the
>> user doesn't have it turned on, no control will give you this feature.
>> .NET is not limited in any way when it comes to controls, it's just that
>> in a web based application (ASP.NET) you don't know what client (browser)
>> the user will have and so you make sure that you only send the client
>> standard code (HTML/CSS?JavaScript). This is the reason that web pages
>> tend to have different data entry controls than in a desktop application
>> (for example, no combobox web forms control). Again, this is not a .NET
>> issue - it's how you make web applications in any development platform.
>>
>>> I guess what I was looking for is an answer to
>>> this question. Is ASP.net a good architecture for a Order/Data Entry
>>> system?
>>
>> Absolutely! As long as you rember my most previous comment above. I
>> can't imagine anything your clients would want that can't be achieved
>> with ASP.NET. You just go about things in a web application a bit
>> differently than you do in a client application.
>>
>>> It just seems as we are building our "demo" we lose alot of the as you
>>> call
>>> it below, interactivity. I'm sure with more practice we can find
>>> workarounds
>>> and still gain the benifets of a web application.
>>
>> Absolutely again! For example, we don't have comboboxes in web
>> applications, but you can certainly place a textbox above a dropdown list
>> and with a little JavaScript combine the two controls so that the user
>> gets the features of a combobox.
>>
>>>> > I have a couple questions, and I'm not sure if this the best forum
>>>> > for
>>>> > answers to these questions but any help, even which forum would be
>>>> > better
>>>> > suited for me is appreciated.
>>>> >
>>>> > 1. Can we use the typed Datasets we have created with the custom BLL
>>>> > with
>>>> > Vb.net. I have yet to see any examples?
>>>>
>>>> Sure. Why not? A DataSet is a class and all .NET classes are designed
>>>> to be
>>>> used in any .NET language (VB.NET being one of them). What language
>>>> did you
>>>> use to build your BLL? Didn't you say it was written in VB.NET? If
>>>> so, you
>>>> are already using DataSets with VB.NET, so I don't really follow your
>>>> question here.
>>>>
>>>> As for examples, haven't you looked at the MSDN library that comes with
>>>> VS.NET? Simply look up DataSet and you'll see all kinds of samples
>>>> using
>>>> VB.NET. Do a google search on VB.NET DataSet and you'll get a plethera
>>>> of
>>>> results.
>>>>
>>>
>>> When I google this I get typed datasets being used in a web application
>>> with
>>> either VB.net or C#. I am trying to use a Typed Dataset we created in
>>> this
>>> manner and import it into a Desktop Application written in VB.net. There
>>> seems to be some issues with the syntax, during the typed dataset init.
>>> it
>>> says the configuration manager is not a member of the configuration
>>> collection. Error # BC30456.
>>
>> This sounds like a simple reference/importing issue. Are you saying the
>> DataSet was created in an ASP.NET project and you are now trying to use
>> it in a windows forms project?
>>
>>>
>>>> > Can someone point me in the direction
>>>> > of where the information to do this would be. In theory with a
>>>> > muti-tiered
>>>> > application I should be able to keep those layers completely
>>>> > independent
>>>> > and
>>>> > use either ASP.net or VB.net correct?
>>>>
>>>> I think you are a bit confused here. ASP.NET is an architecture and
>>>> VB.NET
>>>> is a language. It's not an either or scenario. You build web
>>>> applications
>>>> (ASP.NET is the architecture of .NET web applications) in whatever .NET
>>>> language you choose to work in. Certainly VB.NET can be used to build
>>>> ASP.NET applications.
>>>
>>> I am a bit confused here. I understand with ASP.net you can do the
>>> programming in C# or VB.net and probably many more languages. What would
>>> you
>>> call it when you create the presentation layer and distributatble
>>> application
>>> in VB.net?
>>
>> In ASP.NET there is no distributable anything - - all the processing
>> takes place on your server. Clients use their browsers to connect to
>> your server, your server processes the request and sends the client back
>> a result. All the client has to do is be able to understand what is
>> being sent to it, which is why ASP.NET applications produce HTML, CSS
>> and/or JavaScript - - these are all standard languages that all browsers
>> understand.
>>
>>> That is what I am trying to compare. I guess it would be a web
>>> application vs desktop application?
>>
>> Sounds like it. But, understand that whichever you go with, the language
>> is irrelevant, so you might want to drop "VB.NET" from your analysis as
>> this isn't going to make a difference. "ASP.NET" means web-based
>> application architecture (where the program is run on the server). This
>> can be written in any of the .NET languages. A "Windows Forms"
>> application is one that is distributed (installed) on each client machine
>> that wants to run it (like MS Office). These applications can also be
>> written in any of the .NET languages.
>>
>> In general, web-based applications are the better approach. Here are
>> some pro's and con's:
>>
>> Web-Based (ASP.NET)
>> Pro's
>> 1. Server-side code processing, so you can program in the
>> language/architecture of your choice.
>> 2. Client is only required to have a browser (thin-client).
>> 3. No software installs, updates and patches for the client to install.
>> 4. Application scalability with no client impact.
>>
>> Con's
>> 1. Requires a robust server setup to handle expected volume.
>> 2. Requires security measures be in place and monitored.
>> 3. Can consume large amounts of bandwith.
>> 4. Response time for the client is slower than a desktop application.
>>
>> Hope this helps.
>>
>>
>> -Scott
>>
>>
>>>
>>>>
>>>> > 2. Is Microsoft going to take the Atlas/AJAX controls a step further?
>>>> > Or
>>>> > is
>>>> > there something we can use. I am sure the VB.net controls are much
>>>> > richer
>>>> > because they do not depend on the Windows Web form, but I cannot
>>>> > propose
>>>> > to
>>>> > roll out an application that makes data entry more difficult. Any
>>>> > ideas on
>>>> > how to streamline a ASP.net Web application to make it seem more
>>>> > desktop
>>>> > based? If I can keep the DAL and BLL the same, writing in VB.net and
>>>> > then
>>>> > in
>>>> > a year another rewrite is acceptable, but if we need to re-write
>>>> > those
>>>> > layers
>>>> > as well I will have to look at another plan of attack.
>>>>
>>>> The DAL and BLL have nothing to do with controls since the user doesn't
>>>> interact directly with them. As stated, you can write your DAL and BLL
>>>> in
>>>> whatever .NET language you like. If you feel the web forms controls
>>>> lack
>>>> the interactivity you need, you can look at hosting a windows form from
>>>> a
>>>> web page.
>>>>
>>>> http://www.google.com/search?q=wind...ie=utf8&oe=utf8
>>>>
>>>> >
>>>> > Thanks ahead of time.
>>>> >
>>>>
>>>>
>>>>
>>
>>
>
>

Scott,

I would have written your message almost the same (in my words of course).
However one thing. As soon as you start Hosting Forms Controls, you loose
the possibility to the main goal Rick want to use Webforms instead of
Windowforms. Than you can keep it in my idea with WindowForms.

Cor

What's the point of that?

Thanks,
Robin S.
---------------------------------
"Scott M." <s-mar@nospam.nospam> wrote in message
news:O6CB7hvLHHA.4848@TK2MSFTNGP04.phx.gbl...
> True (and that has really been the point of this thread), but as I
> mentioned in my earlier post, you can host Windows Forms via an
> ASP.NET web page.
>
>
> "RobinS" <RobinS@NoSpam.yah.none> wrote in message
> news:5L6dnc5mCslggwbYnZ2dnUVZ_oipnZ2d@comcast.com...
>> Another con of a web-based application is the UI can not
>> be as robust as it can be if you build the app with Windows
>> Forms -- you don't have as much control.
>>
>> Robin S.
>> ------------------------------------
>> "Scott M." <s-mar@nospam.nospam> wrote in message
>> news:%23JFXSJuLHHA.1248@TK2MSFTNGP02.phx.gbl...
>>> Hi Rick,
>>>
>>> Inline...
>>>
>>> "Rick Vooys" <RickVooys@discussions.microsoft.com> wrote in message
>>> news:98AC2FE4-D6E6-4604-A263-67DF9CC18A12@microsoft.com...
>>>> Much thanks Scott, just to clarify some points the replys are
>>>> inline.
>>>>
>>>> "Scott M." wrote:
>>>>
>>>>> See responses inline...
>>>>>
>>>>>
>>>>> "Rick Vooys" <RickVooys@discussions.microsoft.com> wrote in
>>>>> message
>>>>> news:4863365F-6A07-4CAB-BCB5-17F5D1C4DBC0@microsoft.com...
>>>>> > Quick background, we are upgrading our old Access Application.
>>>>> > We have
>>>>> > upgraded the "backend" or data layer to SQL Server 2005.
>>>>> > Currently we have
>>>>> > the previous Access frontend linked via ODBC and are working on
>>>>> > creating a
>>>>> > new Frontend. The frontend only needs to be accessed via the
>>>>> > company
>>>>> > intranet, but in the future we would like to open up access for
>>>>> > clients to
>>>>> > view certain data.
>>>>> >
>>>>> > For these reasons we wish to use ASP.net, to have a Smart
>>>>> > Client.
>>>>> > Currently
>>>>> > we have designed a DAL and BLL using typed datasets with the
>>>>> > Dataset
>>>>> > designer.
>>>>> >
>>>>> > But as we step through a section of our application, we are
>>>>> > noticing VAST
>>>>> > inadequacies with the web controls and the winform. I.E Combo
>>>>> > boxes do not
>>>>> > exist, the postbacks etc. We have tried some of the AJAX enabled
>>>>> > controls
>>>>> > but
>>>>> > they do not take away all the issues.
>>>>>
>>>>> The web forms controls must render to the client as standard
>>>>> client-side
>>>>> code (HTML/CSS/JavaScript) - - there is no such thing as an HTML
>>>>> combobox
>>>>> and thus, there is no combobox web form control either. This is
>>>>> not a .NET
>>>>> deficciency, it is by design to allow for your client-side output
>>>>> to be
>>>>> consumed by any web client. What "vast" inadequacies have you
>>>>> noticed? It
>>>>> is possible that you just may not be aware of all the
>>>>> functionality of these
>>>>> powerful controls. As for postbacks, why do you list this as a
>>>>> problem? If
>>>>> you manage postbacks properly, you can greatly leverage your code.
>>>>
>>>> I guess in my ignorance, I am not looking into the tools close
>>>> enough. I'm
>>>> sure there is a way to address each of my issues (only one field in
>>>> the drop
>>>> down, no autocomplete, etc).
>>>
>>> Autocomplete is a feature of the browser, not your application. If
>>> the user doesn't have it turned on, no control will give you this
>>> feature. .NET is not limited in any way when it comes to controls,
>>> it's just that in a web based application (ASP.NET) you don't know
>>> what client (browser) the user will have and so you make sure that
>>> you only send the client standard code (HTML/CSS?JavaScript). This
>>> is the reason that web pages tend to have different data entry
>>> controls than in a desktop application (for example, no combobox web
>>> forms control). Again, this is not a .NET issue - it's how you make
>>> web applications in any development platform.
>>>
>>>> I guess what I was looking for is an answer to
>>>> this question. Is ASP.net a good architecture for a Order/Data
>>>> Entry system?
>>>
>>> Absolutely! As long as you rember my most previous comment above.
>>> I can't imagine anything your clients would want that can't be
>>> achieved with ASP.NET. You just go about things in a web application
>>> a bit differently than you do in a client application.
>>>
>>>> It just seems as we are building our "demo" we lose alot of the as
>>>> you call
>>>> it below, interactivity. I'm sure with more practice we can find
>>>> workarounds
>>>> and still gain the benifets of a web application.
>>>
>>> Absolutely again! For example, we don't have comboboxes in web
>>> applications, but you can certainly place a textbox above a dropdown
>>> list and with a little JavaScript combine the two controls so that
>>> the user gets the features of a combobox.
>>>
>>>>> > I have a couple questions, and I'm not sure if this the best
>>>>> > forum for
>>>>> > answers to these questions but any help, even which forum would
>>>>> > be better
>>>>> > suited for me is appreciated.
>>>>> >
>>>>> > 1. Can we use the typed Datasets we have created with the custom
>>>>> > BLL with
>>>>> > Vb.net. I have yet to see any examples?
>>>>>
>>>>> Sure. Why not? A DataSet is a class and all .NET classes are
>>>>> designed to be
>>>>> used in any .NET language (VB.NET being one of them). What
>>>>> language did you
>>>>> use to build your BLL? Didn't you say it was written in VB.NET?
>>>>> If so, you
>>>>> are already using DataSets with VB.NET, so I don't really follow
>>>>> your
>>>>> question here.
>>>>>
>>>>> As for examples, haven't you looked at the MSDN library that comes
>>>>> with
>>>>> VS.NET? Simply look up DataSet and you'll see all kinds of
>>>>> samples using
>>>>> VB.NET. Do a google search on VB.NET DataSet and you'll get a
>>>>> plethera of
>>>>> results.
>>>>>
>>>>
>>>> When I google this I get typed datasets being used in a web
>>>> application with
>>>> either VB.net or C#. I am trying to use a Typed Dataset we created
>>>> in this
>>>> manner and import it into a Desktop Application written in VB.net.
>>>> There
>>>> seems to be some issues with the syntax, during the typed dataset
>>>> init. it
>>>> says the configuration manager is not a member of the configuration
>>>> collection. Error # BC30456.
>>>
>>> This sounds like a simple reference/importing issue. Are you saying
>>> the DataSet was created in an ASP.NET project and you are now trying
>>> to use it in a windows forms project?
>>>
>>>>
>>>>> > Can someone point me in the direction
>>>>> > of where the information to do this would be. In theory with a
>>>>> > muti-tiered
>>>>> > application I should be able to keep those layers completely
>>>>> > independent
>>>>> > and
>>>>> > use either ASP.net or VB.net correct?
>>>>>
>>>>> I think you are a bit confused here. ASP.NET is an architecture
>>>>> and VB.NET
>>>>> is a language. It's not an either or scenario. You build web
>>>>> applications
>>>>> (ASP.NET is the architecture of .NET web applications) in whatever
>>>>> .NET
>>>>> language you choose to work in. Certainly VB.NET can be used to
>>>>> build
>>>>> ASP.NET applications.
>>>>
>>>> I am a bit confused here. I understand with ASP.net you can do the
>>>> programming in C# or VB.net and probably many more languages. What
>>>> would you
>>>> call it when you create the presentation layer and distributatble
>>>> application
>>>> in VB.net?
>>>
>>> In ASP.NET there is no distributable anything - - all the processing
>>> takes place on your server. Clients use their browsers to connect
>>> to your server, your server processes the request and sends the
>>> client back a result. All the client has to do is be able to
>>> understand what is being sent to it, which is why ASP.NET
>>> applications produce HTML, CSS and/or JavaScript - - these are all
>>> standard languages that all browsers understand.
>>>
>>>> That is what I am trying to compare. I guess it would be a web
>>>> application vs desktop application?
>>>
>>> Sounds like it. But, understand that whichever you go with, the
>>> language is irrelevant, so you might want to drop "VB.NET" from your
>>> analysis as this isn't going to make a difference. "ASP.NET" means
>>> web-based application architecture (where the program is run on the
>>> server). This can be written in any of the .NET languages. A
>>> "Windows Forms" application is one that is distributed (installed)
>>> on each client machine that wants to run it (like MS Office). These
>>> applications can also be written in any of the .NET languages.
>>>
>>> In general, web-based applications are the better approach. Here
>>> are some pro's and con's:
>>>
>>> Web-Based (ASP.NET)
>>> Pro's
>>> 1. Server-side code processing, so you can program in the
>>> language/architecture of your choice.
>>> 2. Client is only required to have a browser (thin-client).
>>> 3. No software installs, updates and patches for the client to
>>> install.
>>> 4. Application scalability with no client impact.
>>>
>>> Con's
>>> 1. Requires a robust server setup to handle expected volume.
>>> 2. Requires security measures be in place and monitored.
>>> 3. Can consume large amounts of bandwith.
>>> 4. Response time for the client is slower than a desktop
>>> application.
>>>
>>> Hope this helps.
>>>
>>>
>>> -Scott
>>>
>>>
>>>>
>>>>>
>>>>> > 2. Is Microsoft going to take the Atlas/AJAX controls a step
>>>>> > further? Or
>>>>> > is
>>>>> > there something we can use. I am sure the VB.net controls are
>>>>> > much richer
>>>>> > because they do not depend on the Windows Web form, but I cannot
>>>>> > propose
>>>>> > to
>>>>> > roll out an application that makes data entry more difficult.
>>>>> > Any ideas on
>>>>> > how to streamline a ASP.net Web application to make it seem more
>>>>> > desktop
>>>>> > based? If I can keep the DAL and BLL the same, writing in VB.net
>>>>> > and then
>>>>> > in
>>>>> > a year another rewrite is acceptable, but if we need to re-write
>>>>> > those
>>>>> > layers
>>>>> > as well I will have to look at another plan of attack.
>>>>>
>>>>> The DAL and BLL have nothing to do with controls since the user
>>>>> doesn't
>>>>> interact directly with them. As stated, you can write your DAL
>>>>> and BLL in
>>>>> whatever .NET language you like. If you feel the web forms
>>>>> controls lack
>>>>> the interactivity you need, you can look at hosting a windows form
>>>>> from a
>>>>> web page.
>>>>>
>>>>> http://www.google.com/search?q=wind...ie=utf8&oe=utf8
>>>>>
>>>>> >
>>>>> > Thanks ahead of time.
>>>>> >
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>
>
>

The point is that you ARE able to use Windows Forms & Windows Forms controls
in a web page.


"RobinS" <RobinS@NoSpam.yah.none> wrote in message
news:bIKdnQR816it1AbYnZ2dnUVZ_vShnZ2d@comcast.com...
> What's the point of that?
>
> Thanks,
> Robin S.
> ---------------------------------
> "Scott M." <s-mar@nospam.nospam> wrote in message
> news:O6CB7hvLHHA.4848@TK2MSFTNGP04.phx.gbl...
>> True (and that has really been the point of this thread), but as I
>> mentioned in my earlier post, you can host Windows Forms via an ASP.NET
>> web page.
>>
>>
>> "RobinS" <RobinS@NoSpam.yah.none> wrote in message
>> news:5L6dnc5mCslggwbYnZ2dnUVZ_oipnZ2d@comcast.com...
>>> Another con of a web-based application is the UI can not
>>> be as robust as it can be if you build the app with Windows
>>> Forms -- you don't have as much control.
>>>
>>> Robin S.
>>> ------------------------------------
>>> "Scott M." <s-mar@nospam.nospam> wrote in message
>>> news:%23JFXSJuLHHA.1248@TK2MSFTNGP02.phx.gbl...
>>>> Hi Rick,
>>>>
>>>> Inline...
>>>>
>>>> "Rick Vooys" <RickVooys@discussions.microsoft.com> wrote in message
>>>> news:98AC2FE4-D6E6-4604-A263-67DF9CC18A12@microsoft.com...
>>>>> Much thanks Scott, just to clarify some points the replys are inline.
>>>>>
>>>>> "Scott M." wrote:
>>>>>
>>>>>> See responses inline...
>>>>>>
>>>>>>
>>>>>> "Rick Vooys" <RickVooys@discussions.microsoft.com> wrote in message
>>>>>> news:4863365F-6A07-4CAB-BCB5-17F5D1C4DBC0@microsoft.com...
>>>>>> > Quick background, we are upgrading our old Access Application. We
>>>>>> > have
>>>>>> > upgraded the "backend" or data layer to SQL Server 2005. Currently
>>>>>> > we have
>>>>>> > the previous Access frontend linked via ODBC and are working on
>>>>>> > creating a
>>>>>> > new Frontend. The frontend only needs to be accessed via the
>>>>>> > company
>>>>>> > intranet, but in the future we would like to open up access for
>>>>>> > clients to
>>>>>> > view certain data.
>>>>>> >
>>>>>> > For these reasons we wish to use ASP.net, to have a Smart Client.
>>>>>> > Currently
>>>>>> > we have designed a DAL and BLL using typed datasets with the
>>>>>> > Dataset
>>>>>> > designer.
>>>>>> >
>>>>>> > But as we step through a section of our application, we are
>>>>>> > noticing VAST
>>>>>> > inadequacies with the web controls and the winform. I.E Combo boxes
>>>>>> > do not
>>>>>> > exist, the postbacks etc. We have tried some of the AJAX enabled
>>>>>> > controls
>>>>>> > but
>>>>>> > they do not take away all the issues.
>>>>>>
>>>>>> The web forms controls must render to the client as standard
>>>>>> client-side
>>>>>> code (HTML/CSS/JavaScript) - - there is no such thing as an HTML
>>>>>> combobox
>>>>>> and thus, there is no combobox web form control either. This is not
>>>>>> a .NET
>>>>>> deficciency, it is by design to allow for your client-side output to
>>>>>> be
>>>>>> consumed by any web client. What "vast" inadequacies have you
>>>>>> noticed? It
>>>>>> is possible that you just may not be aware of all the functionality
>>>>>> of these
>>>>>> powerful controls. As for postbacks, why do you list this as a
>>>>>> problem? If
>>>>>> you manage postbacks properly, you can greatly leverage your code.
>>>>>
>>>>> I guess in my ignorance, I am not looking into the tools close enough.
>>>>> I'm
>>>>> sure there is a way to address each of my issues (only one field in
>>>>> the drop
>>>>> down, no autocomplete, etc).
>>>>
>>>> Autocomplete is a feature of the browser, not your application. If the
>>>> user doesn't have it turned on, no control will give you this feature.
>>>> .NET is not limited in any way when it comes to controls, it's just
>>>> that in a web based application (ASP.NET) you don't know what client
>>>> (browser) the user will have and so you make sure that you only send
>>>> the client standard code (HTML/CSS?JavaScript). This is the reason
>>>> that web pages tend to have different data entry controls than in a
>>>> desktop application (for example, no combobox web forms control).
>>>> Again, this is not a .NET issue - it's how you make web applications in
>>>> any development platform.
>>>>
>>>>> I guess what I was looking for is an answer to
>>>>> this question. Is ASP.net a good architecture for a Order/Data Entry
>>>>> system?
>>>>
>>>> Absolutely! As long as you rember my most previous comment above. I
>>>> can't imagine anything your clients would want that can't be achieved
>>>> with ASP.NET. You just go about things in a web application a bit
>>>> differently than you do in a client application.
>>>>
>>>>> It just seems as we are building our "demo" we lose alot of the as you
>>>>> call
>>>>> it below, interactivity. I'm sure with more practice we can find
>>>>> workarounds
>>>>> and still gain the benifets of a web application.
>>>>
>>>> Absolutely again! For example, we don't have comboboxes in web
>>>> applications, but you can certainly place a textbox above a dropdown
>>>> list and with a little JavaScript combine the two controls so that the
>>>> user gets the features of a combobox.
>>>>
>>>>>> > I have a couple questions, and I'm not sure if this the best forum
>>>>>> > for
>>>>>> > answers to these questions but any help, even which forum would be
>>>>>> > better
>>>>>> > suited for me is appreciated.
>>>>>> >
>>>>>> > 1. Can we use the typed Datasets we have created with the custom
>>>>>> > BLL with
>>>>>> > Vb.net. I have yet to see any examples?
>>>>>>
>>>>>> Sure. Why not? A DataSet is a class and all .NET classes are
>>>>>> designed to be
>>>>>> used in any .NET language (VB.NET being one of them). What language
>>>>>> did you
>>>>>> use to build your BLL? Didn't you say it was written in VB.NET? If
>>>>>> so, you
>>>>>> are already using DataSets with VB.NET, so I don't really follow your
>>>>>> question here.
>>>>>>
>>>>>> As for examples, haven't you looked at the MSDN library that comes
>>>>>> with
>>>>>> VS.NET? Simply look up DataSet and you'll see all kinds of samples
>>>>>> using
>>>>>> VB.NET. Do a google search on VB.NET DataSet and you'll get a
>>>>>> plethera of
>>>>>> results.
>>>>>>
>>>>>
>>>>> When I google this I get typed datasets being used in a web
>>>>> application with
>>>>> either VB.net or C#. I am trying to use a Typed Dataset we created in
>>>>> this
>>>>> manner and import it into a Desktop Application written in VB.net.
>>>>> There
>>>>> seems to be some issues with the syntax, during the typed dataset
>>>>> init. it
>>>>> says the configuration manager is not a member of the configuration
>>>>> collection. Error # BC30456.
>>>>
>>>> This sounds like a simple reference/importing issue. Are you saying
>>>> the DataSet was created in an ASP.NET project and you are now trying to
>>>> use it in a windows forms project?
>>>>
>>>>>
>>>>>> > Can someone point me in the direction
>>>>>> > of where the information to do this would be. In theory with a
>>>>>> > muti-tiered
>>>>>> > application I should be able to keep those layers completely
>>>>>> > independent
>>>>>> > and
>>>>>> > use either ASP.net or VB.net correct?
>>>>>>
>>>>>> I think you are a bit confused here. ASP.NET is an architecture and
>>>>>> VB.NET
>>>>>> is a language. It's not an either or scenario. You build web
>>>>>> applications
>>>>>> (ASP.NET is the architecture of .NET web applications) in whatever
>>>>>> .NET
>>>>>> language you choose to work in. Certainly VB.NET can be used to
>>>>>> build
>>>>>> ASP.NET applications.
>>>>>
>>>>> I am a bit confused here. I understand with ASP.net you can do the
>>>>> programming in C# or VB.net and probably many more languages. What
>>>>> would you
>>>>> call it when you create the presentation layer and distributatble
>>>>> application
>>>>> in VB.net?
>>>>
>>>> In ASP.NET there is no distributable anything - - all the processing
>>>> takes place on your server. Clients use their browsers to connect to
>>>> your server, your server processes the request and sends the client
>>>> back a result. All the client has to do is be able to understand what
>>>> is being sent to it, which is why ASP.NET applications produce HTML,
>>>> CSS and/or JavaScript - - these are all standard languages that all
>>>> browsers understand.
>>>>
>>>>> That is what I am trying to compare. I guess it would be a web
>>>>> application vs desktop application?
>>>>
>>>> Sounds like it. But, understand that whichever you go with, the
>>>> language is irrelevant, so you might want to drop "VB.NET" from your
>>>> analysis as this isn't going to make a difference. "ASP.NET" means
>>>> web-based application architecture (where the program is run on the
>>>> server). This can be written in any of the .NET languages. A "Windows
>>>> Forms" application is one that is distributed (installed) on each
>>>> client machine that wants to run it (like MS Office). These
>>>> applications can also be written in any of the .NET languages.
>>>>
>>>> In general, web-based applications are the better approach. Here are
>>>> some pro's and con's:
>>>>
>>>> Web-Based (ASP.NET)
>>>> Pro's
>>>> 1. Server-side code processing, so you can program in the
>>>> language/architecture of your choice.
>>>> 2. Client is only required to have a browser (thin-client).
>>>> 3. No software installs, updates and patches for the client to
>>>> install.
>>>> 4. Application scalability with no client impact.
>>>>
>>>> Con's
>>>> 1. Requires a robust server setup to handle expected volume.
>>>> 2. Requires security measures be in place and monitored.
>>>> 3. Can consume large amounts of bandwith.
>>>> 4. Response time for the client is slower than a desktop application.
>>>>
>>>> Hope this helps.
>>>>
>>>>
>>>> -Scott
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> > 2. Is Microsoft going to take the Atlas/AJAX controls a step
>>>>>> > further? Or
>>>>>> > is
>>>>>> > there something we can use. I am sure the VB.net controls are much
>>>>>> > richer
>>>>>> > because they do not depend on the Windows Web form, but I cannot
>>>>>> > propose
>>>>>> > to
>>>>>> > roll out an application that makes data entry more difficult. Any
>>>>>> > ideas on
>>>>>> > how to streamline a ASP.net Web application to make it seem more
>>>>>> > desktop
>>>>>> > based? If I can keep the DAL and BLL the same, writing in VB.net
>>>>>> > and then
>>>>>> > in
>>>>>> > a year another rewrite is acceptable, but if we need to re-write
>>>>>> > those
>>>>>> > layers
>>>>>> > as well I will have to look at another plan of attack.
>>>>>>
>>>>>> The DAL and BLL have nothing to do with controls since the user
>>>>>> doesn't
>>>>>> interact directly with them. As stated, you can write your DAL and
>>>>>> BLL in
>>>>>> whatever .NET language you like. If you feel the web forms controls
>>>>>> lack
>>>>>> the interactivity you need, you can look at hosting a windows form
>>>>>> from a
>>>>>> web page.
>>>>>>
>>>>>> http://www.google.com/search?q=wind...ie=utf8&oe=utf8
>>>>>>
>>>>>> >
>>>>>> > Thanks ahead of time.
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Hi Cor,

Happy New Year!

It seems that Rick wan't to use ASP.NET, but he also likes his Windows Forms
controls as well. I agree that it may not be the best scenario (I already
told him how he can do things a little differently and still get the
functionality he wants), I was just pointing out the possibility.

"Cor Ligthert [MVP]" <notmyfirstname@planet.nl> wrote in message
news:u2d4v2vLHHA.5064@TK2MSFTNGP04.phx.gbl...
> Scott,
>
> I would have written your message almost the same (in my words of course).
> However one thing. As soon as you start Hosting Forms Controls, you loose
> the possibility to the main goal Rick want to use Webforms instead of
> Windowforms. Than you can keep it in my idea with WindowForms.
>
> Cor
>

Okay; it just seems like a lot more work. Why not just use WinForms?
Robin S.
--------------------
"Scott M." <s-mar@nospam.nospam> wrote in message
news:uT9da4zLHHA.960@TK2MSFTNGP04.phx.gbl...
> The point is that you ARE able to use Windows Forms & Windows Forms
> controls in a web page.
>
>
> "RobinS" <RobinS@NoSpam.yah.none> wrote in message
> news:bIKdnQR816it1AbYnZ2dnUVZ_vShnZ2d@comcast.com...
>> What's the point of that?
>>
>> Thanks,
>> Robin S.
>> ---------------------------------
>> "Scott M." <s-mar@nospam.nospam> wrote in message
>> news:O6CB7hvLHHA.4848@TK2MSFTNGP04.phx.gbl...
>>> True (and that has really been the point of this thread), but as I
>>> mentioned in my earlier post, you can host Windows Forms via an
>>> ASP.NET web page.
>>>
>>>
>>> "RobinS" <RobinS@NoSpam.yah.none> wrote in message
>>> news:5L6dnc5mCslggwbYnZ2dnUVZ_oipnZ2d@comcast.com...
>>>> Another con of a web-based application is the UI can not
>>>> be as robust as it can be if you build the app with Windows
>>>> Forms -- you don't have as much control.
>>>>
>>>> Robin S.
>>>> ------------------------------------
>>>> "Scott M." <s-mar@nospam.nospam> wrote in message
>>>> news:%23JFXSJuLHHA.1248@TK2MSFTNGP02.phx.gbl...
>>>>> Hi Rick,
>>>>>
>>>>> Inline...
>>>>>
>>>>> "Rick Vooys" <RickVooys@discussions.microsoft.com> wrote in
>>>>> message news:98AC2FE4-D6E6-4604-A263-67DF9CC18A12@microsoft.com...
>>>>>> Much thanks Scott, just to clarify some points the replys are
>>>>>> inline.
>>>>>>
>>>>>> "Scott M." wrote:
>>>>>>
>>>>>>> See responses inline...
>>>>>>>
>>>>>>>
>>>>>>> "Rick Vooys" <RickVooys@discussions.microsoft.com> wrote in
>>>>>>> message
>>>>>>> news:4863365F-6A07-4CAB-BCB5-17F5D1C4DBC0@microsoft.com...
>>>>>>> > Quick background, we are upgrading our old Access Application.
>>>>>>> > We have
>>>>>>> > upgraded the "backend" or data layer to SQL Server 2005.
>>>>>>> > Currently we have
>>>>>>> > the previous Access frontend linked via ODBC and are working
>>>>>>> > on creating a
>>>>>>> > new Frontend. The frontend only needs to be accessed via the
>>>>>>> > company
>>>>>>> > intranet, but in the future we would like to open up access
>>>>>>> > for clients to
>>>>>>> > view certain data.
>>>>>>> >
>>>>>>> > For these reasons we wish to use ASP.net, to have a Smart
>>>>>>> > Client.
>>>>>>> > Currently
>>>>>>> > we have designed a DAL and BLL using typed datasets with the
>>>>>>> > Dataset
>>>>>>> > designer.
>>>>>>> >
>>>>>>> > But as we step through a section of our application, we are
>>>>>>> > noticing VAST
>>>>>>> > inadequacies with the web controls and the winform. I.E Combo
>>>>>>> > boxes do not
>>>>>>> > exist, the postbacks etc. We have tried some of the AJAX
>>>>>>> > enabled controls
>>>>>>> > but
>>>>>>> > they do not take away all the issues.
>>>>>>>
>>>>>>> The web forms controls must render to the client as standard
>>>>>>> client-side
>>>>>>> code (HTML/CSS/JavaScript) - - there is no such thing as an HTML
>>>>>>> combobox
>>>>>>> and thus, there is no combobox web form control either. This is
>>>>>>> not a .NET
>>>>>>> deficciency, it is by design to allow for your client-side
>>>>>>> output to be
>>>>>>> consumed by any web client. What "vast" inadequacies have you
>>>>>>> noticed? It
>>>>>>> is possible that you just may not be aware of all the
>>>>>>> functionality of these
>>>>>>> powerful controls. As for postbacks, why do you list this as a
>>>>>>> problem? If
>>>>>>> you manage postbacks properly, you can greatly leverage your
>>>>>>> code.
>>>>>>
>>>>>> I guess in my ignorance, I am not looking into the tools close
>>>>>> enough. I'm
>>>>>> sure there is a way to address each of my issues (only one field
>>>>>> in the drop
>>>>>> down, no autocomplete, etc).
>>>>>
>>>>> Autocomplete is a feature of the browser, not your application.
>>>>> If the user doesn't have it turned on, no control will give you
>>>>> this feature. .NET is not limited in any way when it comes to
>>>>> controls, it's just that in a web based application (ASP.NET) you
>>>>> don't know what client (browser) the user will have and so you
>>>>> make sure that you only send the client standard code
>>>>> (HTML/CSS?JavaScript). This is the reason that web pages tend to
>>>>> have different data entry controls than in a desktop application