Re: newbie question

Hi Lisa,

I think you would benefit from the freely downloadable .Net SDK:

http://www.microsoft.com/downloads/details.aspx?FamilyId=9B3A2CA6-3647-4070-9F41-A333C6B9181D&displaylang=en

No, you won't have any trouble at all learning C#. With a few exceptions,
it's just like C++.

What you WILL take some time to do is to learn the CLR (Common Language
Runtime Library). This is arguably the hardest thing to get familiar with
regarding .Net. There are just so many classes in there. Of course, that's
actually a GOOD thing; as the classes already exist, you don't have to write
as much custom code. Fortunately, the namespaces and classes are organized
extremely well.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"Lisa Pearlson" <no@xxxxxxxx> wrote in message
news:uEeHhMsOFHA.2748@xxxxxxxxxxxxxxxxxxxxxxx
> Thank you for your feedback. I really appreciate it, and I did not dismiss
> anything.
> I'm an experienced C++ programmer. I'm not worried about learning C#.
>
> I do not expect people to support me in my .NET dislike or all other
> layers of abstraction, starting with COM. I understand the advantages, but
> not sure it needs to be that complex. If I wanted to to be affirmed in my
> dislike, I wouldn't be posting on a microsoft news server, but on a linux
> website.
>
> My sole purpose was to learn enough about .NET to know if it can be a
> better tool for the job.. (not only technically, but also market
> acceptance.. if customers want it, and maybe later want connectivity with
> other microsoft products, then using microsoft products is a better
> choice, even if I hate it.. I have to give what the customer wants. I'm
> accepting my miserable fate).
>
> At least I'm not dimissing .NET indefinitely.. For me to judge if it is
> the right tool for the job or not, I need to know enough about it to be
> able to make that judgement, and I don't know enough yet.
>
> Your response has helped me quite a bit.. and I am leaning towards using
> PHP has a draft, and then program a windows C++ application with ODBC.
> Perhaps even embed HTMLView so I can use the ease of web as well as power,
> flexibility and speed of C++.
>
> I'm not done learning about .NET yet though.. If you can't beat them, join
> them.. resistence is futile, we'll all be victimize by this monopoly. :-)
> owwwww
>
> "Dave Fancher" <eijitek@xxxxxxxxxxx> wrote in message
> news:0_ednchVhaEe4M7fRVn-rg@xxxxxxxxxxxxxx
>> For what you have described, ASP.NET doesn't sound like the tool for you.
>> You want a client side technology (ActiveX or Java?) that is able to
>> create and maintain a connection to a database. You don't need ASP.NET
>> for what you have described. I think a desktop application is better
>> suited for this application.
>>
>> To fill you in, the way the event model works in ASP.NET is that each
>> control that triggers a server side event calls a client side JavaScript
>> function that sets the value of a couple of hidden fields then submits
>> the form (a standard HTML form with a runat="server" attribute). There
>> is another hidden field called ViewState that allows for persisting
>> values between server trips. Additionally, each page follows a specific
>> life cycle of events that handle code specific to intialization, loading,
>> event handling, rendering, and unloading.
>>
>> For instance, if you have a Button WebControl (rendered as <input
>> type="button" ...>) that has a server side handler for onClick, the
>> button is also rendered with onclick="__doPostBack(...);" which sets the
>> hidden fields and submits the form. The .NET runtime (on the server)
>> checks the value of the hidden fields (including viewstate) to determine
>> the status of the page and executes the method that is specified to
>> handle the event.
>>
>> The model used by ASP.NET allows for much more managable code not to
>> mention that is succeeds in isolating the logic from the UI code (HTML)
>> since, when done properly with code behinds (VS.NET default), the HTML
>> document (your aspx file) forms the layout for a class ultimately derived
>> from System.Web.UI.Page. With a code behind, you define a class derived
>> from System.Web.UI.Page. When an ASPX is requested, the runtime
>> instantiates a class derived from the class defined in the code behind
>> file.
>>
>> If all your application needs to do is retrieve and edit database
>> records, you may be able to pull this off in a month but that entirely
>> depends on the actual complexity of the app. Overall, the WebControls
>> and HtmlControls are pretty straight forward. ADO.NET is also pretty
>> straight forward. Depending on your environment and application needs
>> though, security considerations (which it sounds like you'll have from
>> your issues over control) offer their own set of complications. Of
>> course, there are nuances to all of these topics about which you should
>> educate yourself.
>>
>> Agreeing with Scott M., IIS is easy to configure. I'm running six
>> ASP.NET apps and have development, testing, and production environments
>> set up for each of them. Very little configuration is needed to properly
>> configure IIS for an ASP.NET application. Granted, IIS configuration is
>> not done through config files but to argue your point about Apache
>> working "out of the box", you said it yourself, "configure some options
>> in a config file, ..., install PHP, ... and off you go." How much does
>> that really differ from "install the .NET Framework, click a button or
>> two to configure some options, and off you go." In either case, you must
>> still create the application folder and tell the HTTP server where the
>> application is loaded.
>>
>> As for learning the .NET technolgies, learning a .NET language shouldn't
>> be a big deal. If all else fails you could even use PerlASPX from
>> ActiveState to allow you to use Perl instead of C#. Sure, there are
>> differences between languages in that some languages offer features that
>> other languages don't but the overall concepts are the same and common
>> constructs are only syntactically different. No matter how it is
>> written, a for loop is still a for loop.
>>
>> When push comes to shove and you're up against a wall, you need to choose
>> the best tool for the job. For your situation, it sounds like you should
>> stick with a tool with which you are already familiar. In fact, your
>> posts read as though you have already convinced yourself not to use the
>> .NET technologies for a variety of reasons that are applicable in some
>> cases and not in others. You seem to be dead-set against using the .NET
>> technologies and are looking for people working in completely different
>> environments with different needs to either validate your concerns
>> (further proving that .NET is not worth your time) or to give you some
>> irrefutable argument as to why you absolutely must use .NET as opposed to
>> the other tools at your disposal. To reiterate, you must evaluate the
>> needs of the project and choose the tool that you believe will best meet
>> those needs. If you believe ASP.NET is the best tool, great, use it,
>> otherwise use something else.
>>
>> On a side note, if you're dismissing at least 80% of what you read, it
>> sounds like you may want to refine your search techniques or perhaps
>> you're simply disregarding too much...
>>
>> Good luck with your project.
>> ----------------
>> Dave Fancher
>> http://davefancher.blogspot.com
>>
>> "Lisa Pearlson" <no@xxxxxxxx> wrote in message
>> news:%23B8LrZlOFHA.1396@xxxxxxxxxxxxxxxxxxxxxxx
>>> Thank you for your response.
>>>
>>> I find that most of my time learning new stuff is wasted on searching
>>> for the right info.. and digging through 80% or more of useless chatter
>>> around it, yet having to read it all to know what is chatter and what is
>>> not.
>>>
>>> If you're a good programmer, you can make applications robust and
>>> scalable without the .NET framework. But since .NET is advertised well
>>> and clueless customers want it, I'm pretty much forced to swallow this
>>> new technology which is yet again another wrapper around all these
>>> microsoft technologies, that I frankly dislike. One reason why I never
>>> liked VB. To much behind the screen wiring.
>>>
>>> Anyway, I should be able to develop something within 1 month, and maybe
>>> fine tune things later.. doing the project will be like following a
>>> tutorial, where I have to search the net for clues as to how to take the
>>> next step. Best way to learn.. But pretty stressful when you have a
>>> deadline too.
>>>
>>> Away from my petty life, back to ASP.NET, you mention "event driven
>>> model".. I'm sure all this info is available on the net, but like I
>>> said, 80% of my time is wasted on searching for it, so this helps me
>>> alot..
>>>
>>>
>>> Question:
>>> How should I understand event driven model in web applications? on
>>> client side, javascript can handle some events, everything else is
>>> usually done via form POST and parsing on the server side, using ASP,
>>> PHP or whatever.
>>> Do events on the client side get sent to the server? Via HTTP messages,
>>> or via DCOM bloat?
>>>
>>>
>>>
>>> I've found so many sources dealing with ASP.NET but none that just
>>> explain some of the basics of what ASP.NET is really all about. I've
>>> read upon some .NET stuff, and it seems little more than a thin wrapper
>>> around windows APIs to handle some garbage collection and such.. (to
>>> use api's you have to write your own wrappers sometimes.. reminds me of
>>> VB, where to do anything useful, required you to import half the windows
>>> api's.. so then why not use VC++ instead, I always wondered).
>>>
>>> Lisa
>>>
>>
>>
>
>


.

Loading