|
What about "IE5 or above" ?? 
Auch den Schatten will ich lieben weil ich manchmal lieber frier' Rosenstolz [sighist]
|
|
|
|
|
I can't remember if 2000 and/or 98 come with IE5. If so, then that's not *too* bad.
Certainly not IE6 or above. 
Even a broken clock is right twice a day.
|
|
|
|
|
W2K & 98 SE yes, 1st ed no
IE5 has far improved DHTML access from the outside, which we need now and then.
Navin wrote:
Even a broken clock is right twice a day.
Which you can't say of most clocks that "work". nonetheless people seem to prefer them
Auch den Schatten will ich lieben weil ich manchmal lieber frier' Rosenstolz [sighist]
|
|
|
|
|
Nine times out of ten it is cheaper and quicker for us to write our own components because nine times out of ten the problems we face are not that difficult.
It is only when we come up against something that will take a solid month or two to figure out and code that we will hunt for a component that does it for us.
Remember that cost of training and implementation with 3rd party components is quite high while with having written your own component the cost is much lower.
Also being in web dev we get the odd client who refuses to allow any 3rd party components on their servers. Even if we are hosting the solution some clients do not want 3rd party components for fear that the component manufacturer will go out of business and they will be left with an unknown component.
All I can say is thank god the .NET Framework has some fundamental components which normally required 3rd party components in ASP (.e.g uploading, image manipulation etc.)
|
|
|
|
|
So... what is the difference between a third-party component vendor going out of business, or you (as the developer) moving on to something else?? Would the availability of source code be the issue?
Plus, now that .NET components run in a secured manner, would you be more willing to use them, since they allow X-Copy deployment?
I don't mean to annoy you with all of these questions, but as a person in a component development business the more I understand what developer's wants and concerns are the better.
Troy
|
|
|
|
|
Troy Marchand wrote:
So... what is the difference between a third-party component vendor going out of business, or you (as the developer) moving on to something else??
Good point. But there is a difference in the relationship between us and the client, and the client and the 3rd party component developer.
First of all most clients check to see if we are an established company and looking to be around for a good time to come. They cannot really do that with 3rd party component developers that we want to use as they do not know much about them.
Sure we could, for the client, check up on the component developer, but no client is really going to be 100% trustful that our checks are thorough. And so they shouldn't be because we do not have the resources to do a thorough check.
Also we give a warranty period on any project we do and that is between us and the client. With a 3rd party component any warrantys, guarantees, support etc. is between us and the developer, not the developer and the client.
Another thing is that there is more "proprietary" knowledge required in using a 3rd party component than, lets say, doing it straight in ASP or whatever the language it is. So if we did go bang and the client needed some more work done and a 3rd party component was used then the client would have to invest more money into either finding someone who had used the component, or invest more money into training their new developers in the workings of the component (plus of course the project we provided itself. )
Other issues surround support (once again the support agreement is between you and I, not you and my client) and liability.
All in all some clients refuse 3rd party components. Others refuse to allow 3rd party components unless source code is provided (but some back out of that route when they see the price for getting the source code  .)
Troy Marchand wrote:
I don't mean to anoy you with all of these questions, but as a person who a component development business the more I understand what developer's wants and concerns are the better.
Not annoying at all and I enjoy fleshing out my own thoughts on the matter. And I am always happy to help out fellow developers.
We as a company would never get into strict component development (we may release components but they would be for free and more as a marketing thing than a cash generator) but effectively we do do component development and use them in all our projects for clients. Some call it re-usable code 
|
|
|
|
|
If I have enough time to make my own, I'd prefer to do it rather than use someone else's. This way I can also learn new things
Philip Patrick
Web-site: www.stpworks.com
"Two beer or not two beer?" Shakesbeer
|
|
|
|
|
With the amount of the spy-ware we have nowadays I only trust and use the components that come with the source code.
Anything else seems to be a plain suicide. 
<center> </center>
|
|
|
|
|
I want source code for the ability to step into when debugging, this can avoid "GPF on xxx.DLL at address yyyy", reduce error search pain and help product like BoundsChecker to spot errors.
|
|
|
|
|
George wrote:
With the amount of the spy-ware we have nowadays
Not to mention the likelyhood that several years down the road, nasty little assumptions made by the component about environment, platform, and purpose will become invalid, thus creating ugly maintenance issues for your software...
Shog9
------
No one's immune now, from a world of problems
No one's exempt now, from a world of pain
That's the way that it goes
when you're down here with the rest of us...
|
|
|
|
|
And then God created .NET and the Common Language Runtime and saw that they were good. He said "Be fruitful and Multiply" And he sayeth further, "Thou shalt be open with thy source code, for it is useful."
It's good to see kids turning their minds to wholesum activities such as programming, instead of wasting their lives in the hedonistic disciplines of Sex, Drugs, & Rock & Roll... or Sex with Drugs, or Sex with Rocks while Rolling in Drugs, or whatever new-fangled perversions you little monsters have thought up now...
[Shog9 on Kid Programmers]
|
|
|
|
|
Or just because you want to change it... not to say to fix the bugs they made 
|
|
|
|
|
I agree - being dependent on any kind of 3rd party component without having the source is just plain dangerous. Especially if the company goes out of business... or changes its component dramatically... or you simply want to be able to debug and/or change your stuff...
Even a broken clock is right twice a day.
|
|
|
|
|
George wrote:
With the amount of the spy-ware we have nowadays I only trust and use the components that come with the source code
What about things like the .NET Framework and how did you react to MFC and ATL (or is it WTL? not sure... ) when they came out?
Isn't it more about trust than the "only use if source code available" rule?
I know I happily dove into the .NET Framework (which is one big set of components right?) but balked a bit when asked to use a simple Dundas* control.
* Only because coming from a web dev and VB background my exposure to Dundas has been minimal
|
|
|
|
|
Paul Watson wrote:
What about things like the .NET Framework and how did you react to MFC and ATL (or is it WTL? not sure... ) when they came out?
You are mistaking the frameworks and the components here. .NET is not a third party component by any means. It is a first party product and out of the scope of this poll.
Anyhow, MFC when it first come out was a great piece of engineering and it managed easily to put Borland out of business. It is still a great library, and it actually does come with full source code.
<center> </center>
|
|
|
|
|
George wrote:
You are mistaking the frameworks and the components here. .NET is not a third party component by any means.
The .NET Framework is essentially a set of components made my Microsoft, a 3rd party
Obviously I am not talking about IL, GC etc. etc. But System.Xml, System.Data, System.FUBAR etc. are all collections of code which can be re-used as needed, just like a 3rd party component.
Also currently the .NET Framwork is treated much as a 3rd party component with many of our clients. A: They do not want it on their hosting server until all the bugs are out and B: They are afraid that if we go bang and have developed a .NET app then they will not be able to easily find a developer who knows .NET to maintain and extend the solution. Same story with 3rd party components.
Also if you consider that any properly made piece of code I do in .NET is as "valid" and "real" as a Microsoft class/struct/whatever then what is the diff.?
Anyway so that is what I was getting at. That the issue is not source code but trust. We treat collections of code from Microsoft differently to how we treat it from other 3rd parties, like Dundas. The .NET Framework classes are just a bigger collection of components than we normally handle and we treat it more as a system.
That is why I asked about MFC and ATL etc.
George wrote:
It is still a great library, and it actually does come with full source code.
What if source code was not available for MFC? Would it's adoption have been as thorough?
|
|
|
|
|
Paul Watson wrote:
What if source code was not available for MFC? Would it's adoption have been as thorough?
Probably not. I know I (and I'm sure many other developers did, too) thought the best thing about MFC was that it came with full source code. That is invaluable when trying to debug - even if it is your piece of code that's breaking, sometimes you just have to see what's going on inside to get a good grasp of the situation.
Then there is also "code cloning"... maybe you see an MFC class that does almost what you want, but not quite, so you have to copy-and-paste to do what you need. Though if component developers design their components better, the need for doing this kind of thing is minimized.
One of the biggest disadvantages of .NET is that you don't get the source to all the common stuff. It is no better than the Win32 API in that regard... you do something, it is pretty much a black hole. If something happens that you don't expect, good luck figuring out what's going on.
Given a choice between component X and component Y that both can do what I need, I'll take the one with full source, thank you.
Even a broken clock is right twice a day.
|
|
|
|
|
Paul Watson wrote:
The .NET Framework is essentially a set of components made my Microsoft, a 3rd party
A third-party component, as I understand it, is a single piece of code that can exist on its own in a particular environment and which comes as such component. .NET Framework is an environment in which you can plant a third party components. Framework might be build from the set of components, but since it exists and makes sense only as a set or its large part it can't be called a third-party one. You don't buy these separately, they all come together as a package, a framework.
Paul Watson wrote:
Anyway so that is what I was getting at. That the issue is not source code but trust. We treat collections of code from Microsoft differently to how we treat it from other 3rd parties, like Dundas.
If I have the source code I don't have to trust any more - because I, and many others, can verify what's going on in the component. That makes the whole difference!
Also, while we are at it - my trust to Microsoft is close to zero recently and going down each day. When MFC first came out it was the whole different company making a great products. Now it's just a greedy bastard trying to take over the world 
Paul Watson wrote:
What if source code was not available for MFC? Would it's adoption have been as thorough?
We will never know for sure, there was many factors that helped MFC to become popular. One of which was the clumsiness of the competitors like Borland. When they were starting with OWL it was not so sure which framework would prevail. But Borland made a few strategic mistakes and so MFC has won in the long run. At the same time MS provided a great development environment and it all "clicked" together. I am not sure about the .NET thought because it seems like MS is pushing it too hard. From the Visual C++ perspective it's a huge step back and many people upgraded from VC70 back to VC60 already. I am seriously considering to move to another compiler, like Intel's for example. It's a very good product and quite cheap in comparison with VS.NET. Call it a third-party compiler
<center> </center>
|
|
|
|
|
The problem is that software editors generally hesitate to divulge the source code, especially if it is the result of several years of development.
|
|
|
|
|
You need several years to earn $500?
If this is a question of money, then the less expensive choice is to purchase the component, because if you develop it yourself, the price will be 100 times more expensive. Ok, in such a case, you would have the source code... which is perfectly useless in 99% of the cases!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
