|
I am having problems running a C# application which uses mschart 6.0 on
machines with just .NET Framework installed.
If I run this application on a machine with the full Visual Studio .NET 7.0
installed then it runs just fine.
My application is very simple, I have a form and added the mschart 6.0 (an
activeX control) onto the form without
any code changes. I then compiled the project and copied the following
files to a machine with just .NET Framework installed:
- the generated exectuable
- AxInterop.MSChart20Lib.dll
- Interop.MSChart20Lib.dll
Once I run the generated executable I am getting the following error:
"Application has generated an exception that could not be handled.
Process id=0x960(2400), Thread id=0x504(1284)"
I even went as far as creating a dialog application in Visual C++ 6.0 and
added the same mschart object on the dialog.
This app runs just fine on the same machine with just .NET Framework
installed which proves that the ActiveX control
was registered correctly.
I have also confirmed that this problem exists only for the mschart activeX
control. I created another
C# form and added other ActiveX Control such as DateTimePicker and it worked
just fine on the machine with just
.NET Framework installed.
Any help is greatly appreciated.
|
|
|
|
|
|
I've configured several COM components to support transactions, and they are called by my C# serviced component, which is configured to require a new transaction.
However my component fails on the first COM call, with an error saying that the new transaction could not enlist in the specified transaction coordinator.
I'm new to this, any help would be appreciated.
The DJ's took pills to stay awakwe and play for seven days. - Jim Morrison, Black Polished Chrome.
|
|
|
|
|
|
Yes.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
|
How can I add a column dynamically to a datagrid in Winforms.
Thanks,
RP
|
|
|
|
|
|
I'm starting to seriously consider the possibility that you wrote this book and are trying to promote it with this non-question day after day.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Hi,
I have attempted to connect via remote registry (RegistryKey.OpenRemoteBaseKey) to ~400 computers in our organization's intranet. Although I am doing my best to free resources (even call GC.Collect manually), I notice a Thread & System resources handles leak which hangs my system after ~350 computers.
Is anyone aware of such a problem / known issue in .NET (v1.1) ?
Thanks in advance,
I. Chen
|
|
|
|
|
There is no known leak like that. It's common to miss Disposing various objects though.
You should also not be calling GC.Collect yourself unless you know precisely why your doing it and what the consequences are. Since the GC is self tuning, forcing it to run can cause the GC to not maintain managed resources efficiently and actually slow down your app.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
i.chen wrote:
even call GC.Collect manually
This is almost certainly hurting performance. Make sure you make use of the using keyword in C#, or if you're in VB.NET, just make sure you dispose of all your objects, like Dave said.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
|
hey people do you have developed ASPNET Online TV & Radio Example?
My Finding language:Visual Basic.NET & C#.net ASPNET & .NET Framework & Windows Application
I need Your Help Quickly
Ahmed Erarslan
MCAD,MCDBA,MCP
MCSD.NET
|
|
|
|
|
Well, after 19 years working with the various generations of FoxPro, and watching it languish under Gates' "stewardship", I decided I should get with it and begin developing with the .Net tools. So I ponied up my hundreds and eagerly sat down, expecting to be thrilled with the latest technologies.
Within the first week, I found that the so-called Data Adapter "Wizard" not only fails but corrupts my forms so badly that I need an intermediate level of knowledge to repair them.
Then, I find that a simple hot-key combination for on onscreen "Save" button causes a loss of the latest edited row.
Then, it turns out that putting a combobox in a grid requires creating a special (and for me, sophisticated) object. VFP has supported this for nearly 10 years now.
Now, I am unable to find any easy way to have SQL Server's default field values written to new records added on my grids.
And so, with a disappointment bordering on disgust, I find myself again wondering why all Bill's Billions cannot create a development environment with rudimentary functionality.
My question is:
Is .Net really a step up from other IDEs, or am I going to find myself having to rig up countless unforseen kludges to create a streamlined, user-friendly app?
Take Care,
Karl
Take Care,
Karl Kaiser
|
|
|
|
|
It depends on what the IDE is designed to achieve. The VFP IDE obviously had to achieve more on the data binding front, while Visual Studio and the .NET Framework are more generic as they have to work with a more diverse set of intended applications.
I'm sure that .NET is capable of doing everything that you want, it just takes a bit more effort in some areas. For my self, coming from a C++ background .NET and C# are a leap forward, but then I was following through from previous versions of Visual Studio, not crossing from a different product.
My: Blog | Photos
WDevs.com - Open Source Code Hosting, Blogs, FTP, Mail and More
|
|
|
|
|
KaiserKarl wrote:
Is .Net really a step up from other IDEs, or am I going to find myself having to rig up countless unforseen kludges to create a streamlined, user-friendly app?
The latest versions of Visual Studio are a big step-up from previous versions. Where as FoxPro provided a data-centric interface as it was always a data-based tool. Visual Studio has a far larger remit and so doesn't currently have the tools that we take for granted in FoxPro. We still have to write code or use 3rd party tools.
Visual Studio 2005 is a big improvment over 2003 (IMO) and the next version after that promises to address some of the database issues.
Michael
CP Blog [^] Development Blog [^]
|
|
|
|
|
KaiserKarl wrote:
after 19 years working with the various generations of FoxPro,
It sounds to me like you've locked yourself into a product that, right or wrong, was bought by Microsoft for the express purpose of killing it. I'm sure that there are issues like the ones you describe which would frustrate me in Foxpro, but which you take for granted because you've learned them over time.
KaiserKarl wrote:
Within the first week, I found that the so-called Data Adapter "Wizard" not only fails but corrupts my forms so badly that I need an intermediate level of knowledge to repair them.
Personally, I avoid all wizards, and take the time to learn how to write my own code.
KaiserKarl wrote:
Then, I find that a simple hot-key combination for on onscreen "Save" button causes a loss of the latest edited row.
Edited row ? Are you using SQL Server, or VS.NET ? You shouldn't use VS.NET to edit your database, no matter what tools it seems to provide. That's what Enterprise Manager and Query Analyser are for.
KaiserKarl wrote:
Then, it turns out that putting a combobox in a grid requires creating a special (and for me, sophisticated) object. VFP has supported this for nearly 10 years now.
I'm sure Access does to. In fact, I know it does. However, the .NET framework is relatively young, and grids don't exist at all in the underlying Windows control library. You're just experiencing initial learning curve, it's not really that complex. In any case, this website has a lot of example code you could download for this sort of thing.
KaiserKarl wrote:
Now, I am unable to find any easy way to have SQL Server's default field values written to new records added on my grids.
You have an app with a datagrid, and you want to see the default values appear when you create a new record ? Just create a new record and redatabind, they should appear, no problems.
KaiserKarl wrote:
Is .Net really a step up from other IDEs, or am I going to find myself having to rig up countless unforseen kludges to create a streamlined, user-friendly app?
VS.NEt 2003 is a small step from 2002, which was itself a major step at the time. I'd say VS2005 is another major step forward in many ways. The only thing is, you're experiencing an initial learning curve, after 19 years in the one comfort zone. Stick with it, you'll be fine.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Thanks for taking the time to write, Christian (and y'others). I didn't expect specific answers, but just an overall sense of how much work I am getting into here. Frankly, in my pompous opinion, over 20 years after the PC revolution, that a developer would have to hand-code basic UI processes for a data maintenance app (including combo-boxes in grids) points to a glaring failure of craftsmanship at MicroSoft (maybe they don't have the funds?!).
Here are some specific responses to Christian, with one question at the end.
It sounds to me like you've locked yourself into a product that, right or wrong, was bought by Microsoft for the express purpose of killing it.
It seems to me in recent years that MS did not want to extend or even adapt VFP, but to let it slowly starve and hope the developers would stick with MS anyway. While I may be "locked in" as you say, it wasn't me who did the locking!
FWIW, I once entered my product in an MS-sponsered competition and, while the judges thought it to be potentially the best app in its class, the word was they would not (could not?) award a VFP-based product.
Personally, I avoid all wizards, and take the time to learn how to write my own code.
Well, if you've got the time to take, then good for you. In any case, one would hope that any so-called Wizards would actually be useful and at the least, not destructive, that is, "Wizards" in the Gandalf vein, not the Saruman vein.
Then, I find that a simple hot-key combination for on onscreen "Save" button causes a loss of the latest edited row.
...Edited row ?
Very simple: create a basic windows app with a DataConnector-DataAdapter-DataSet cx to SQL server (as described in the documentation) and a datagrid. Put in a "Save" button to call the Adapter's "Update" method. Run the app and create a record and press the button. Everything works fine.
Now, change the button text to implement a hotkey (ala "&Save"). Now, go edit a record, and, without leaving the record, press the hotkey sequence. The Update method is triggered but no data is written over and no error returned.
I don't want to get too dramatic, but to me this is a ghastly failure in such a presumably sophisticated product.
You have an app with a datagrid, and you want to see the default values appear when you create a new record ? Just create a new record and redatabind, they should appear, no problems.
I'm not sure what you mean here. Are you suggesting that I first insert the record at the database and then select it out to the client in order to populate the defaults (I hope not!).
Otherwise, it does seem that the upcoming VS .Net 2005 has some useful features, like native support for a combobox in a grid, that will help get me over the hump.
Thanks,
Karl
Take Care,
Karl Kaiser
|
|
|
|
|
KarlKaiser wrote:
Frankly, in my pompous opinion, over 20 years after the PC revolution, that a developer would have to hand-code basic UI processes for a data maintenance app (including combo-boxes in grids) points to a glaring failure of craftsmanship at MicroSoft (maybe they don't have the funds?!).
Well, you have to face the fact that you're using a programming language now, not a framework designed to support a database 
KarlKaiser wrote:
It seems to me in recent years that MS did not want to extend or even adapt VFP, but to let it slowly starve and hope the developers would stick with MS anyway.
Like I said, they bought it to kill it. Yes, it was you who decided to stick with a product whose life cycle was obviously in the process of being cut short.
KarlKaiser wrote:
Well, if you've got the time to take, then good for you.
Well, I like to know what I'm doing. The VC6 wizard used to make a mess at times, and if you didn't know what it was doing, it was hell to tidy up.
KarlKaiser wrote:
I don't want to get too dramatic, but to me this is a ghastly failure in such a presumably sophisticated product.
To be honest, once again, I never play with the stuff you're using, I'd prefer to be writing code that calls my own stored procedures instead of asking a datagrid to update itself to the database.
KarlKaiser wrote:
Are you suggesting that I first insert the record at the database and then select it out to the client in order to populate the defaults (I hope not!).
If you don't want to have to fill the values in yourself, that is exactly what you need to do. Otherwise, you need to populate the values yourself. There is no connection between the database and the app, ADO.NET is a disconnected framework.
The core issue is that FoxPro is basically a database system, and whatever language you happen to be using now ( C# or VB.NET ? ) is a language with far more usefulness and potential than FoxPro could ever have had. That it doesn't automagically do everything you'd like in the database realm is a reflection perhaps of how new the framework is, but also how much more it is than a system for putting together data centric business apps. And like I said, everything you're talking about, I can do effortlessly, in seconds. I'm sure if I had to learn FoxPro and you were watching, you'd be surprised at the things I complained about, because you could do them just as easily.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Hey Christian,
Well, you have to face the fact that you're using a programming language now, not a framework designed to support a database
Do I sense that this pesky third-tier is intruding on your rarefied world of "pure code"??!! 
I guess I haven't yet bought into the assumption that these must be mutually-exclusive technologies. (And you wouldn't know it from MicroSoft's positioning of its own product!)
[...MS did not want to extend or even adapt VFP, but to let it slowly starve...]
Yes, it was you who decided to stick with a product whose life cycle was obviously in the process of being cut short.
Well, I don't know how or when MicroSoft's intention to "kill" VFP became "obvious" to you--they certainly never confessed this--but it was only obvious to me in the past 3-4 years.
I never play with the stuff you're using, I'd prefer to be writing code that calls my own stored procedures instead of asking a datagrid to update itself to the database.
Well I guess it depends on who is paying for your coding. I'm in the business of creating and maintaining a complex vertical market database app. I can't let my preference to code or not code get in the way of optimizing development if I'm going to say in business.
[Are you suggesting that I first insert the record at the database and then select it out to the client in order to populate the defaults (I hope not!).]
If you don't want to have to fill the values in yourself, that is exactly what you need to do. Otherwise, you need to populate the values yourself. There is no connection between the database and the app, ADO.NET is a disconnected framework.
Well now that is kludgy. That means I'll have skeleton records in the server DB during the user's edit session. Then, if they cancel out I'll either have to run Delete calls or else run the whole edit session in a transaction.
...Call me niave, but, it seems to me that if the sqlDataAdapter is already fetching the fields' data types, size, null status, etc. why not fetch the default value and populate it where possible when inserting (locally) a new record?
That [C# and .Net] doesn't automagically do everything you'd like in the database realm is a reflection perhaps of how new the framework is, but also how much more it is than a system for putting together data centric business apps.
While I don't dispute what else C# can do, I think a recurrent theme here in our conversation has been MicroSoft's conceit/deceit in positioning .Net in most every communication (from marketing to help documentation) as a powerful dev tool for database applications.
This is especially unfortunate, because over the years I've seen many software ventures either crippled or completely fail for the difference between what MicroSoft says it's tools can do and what they really do.
Take Care and go Code!
Karl
Take Care,
Karl Kaiser
|
|
|
|
|
KarlKaiser wrote:
Do I sense that this pesky third-tier is intruding on your rarefied world of "pure code"??!!
LOL - well, I'm using C# as well, so it's hardly 'pure' code.
KarlKaiser wrote:
mutually-exclusive technologies.
Not at all, it's just that their resources are pulled in a lot more directions than they would be if they were just creating another database with some programming support.
KarlKaiser wrote:
Well, I don't know how or when MicroSoft's intention to "kill" VFP became "obvious" to you--they certainly never confessed this--but it was only obvious to me in the past 3-4 years.
Yeah, I guess it's been obvious to me for only a little longer than that.
KarlKaiser wrote:
Well I guess it depends on who is paying for your coding. I'm in the business of creating and maintaining a complex vertical market database app. I can't let my preference to code or not code get in the way of optimizing development if I'm going to say in business.
It really takes you that long to write a simple stored proc to do a data update ? I'm paid to work on large ASP.NET systems, I find they work better if I take control of the code that gets run, especially the data layer.
KarlKaiser wrote:
Well now that is kludgy. That means I'll have skeleton records in the server DB during the user's edit session. Then, if they cancel out I'll either have to run Delete calls or else run the whole edit session in a transaction.
No, it means that you don't 'create' the record until the values have been entered. The DataGrid has good support for this sort of behaviour. Why do you need to create a record on the DB before the values have been entered ? I would agree that the disconnection between the defaults you show and the defaults enforced by the DB can be a kludge, unless you don't have defaults in the DB and let the UI enforce them instead.
Basically, ADO.NET moved to a disconnected framework because of ASP.NET - because it's gonna be used a lot on web apps.
KarlKaiser wrote:
...Call me niave, but, it seems to me that if the sqlDataAdapter is already fetching the fields' data types, size, null status, etc. why not fetch the default value and populate it where possible when inserting (locally) a new record?
Because that's not it's job. It's job is to run a query, not to additionally ask for other details that generally aren't needed, and that will hurt performance.
KarlKaiser wrote:
I think a recurrent theme here in our conversation has been MicroSoft's conceit/deceit in positioning .Net in most every communication (from marketing to help documentation) as a powerful dev tool for database applications.
.NET *is* a powerful tool for building database applications, and a great leap forward from the way it was done in C++. A *huge* leap, in fact. I use it for this purpose every day, and I used to use ADO/C++, so I speak from experience. But it's also a great tool for building a ton of other things, and in every case, it's moving away from a more complex coding model, not from a system like Access or FoxPro, which is custom built for one task and therefore does a lot more hand holding, at the expense of a lot of flexibility.
KarlKaiser wrote:
This is especially unfortunate, because over the years I've seen many software ventures either crippled or completely fail for the difference between what MicroSoft says it's tools can do and what they really do.
It's always wise not to take marketing at face value, and to research a vendors claims before betting the farm on them. That holds as true for Microsoft as anyone else.
I'm not remotely claiming that .NET is perfect, or even that it's better than FoxPro at writing databases. I do still think that a lot of the trouble is that you're noticing the things that FoxPro used to do more than the things you can now do in .NET. I was the same when I first moved to C#, from C++ ( although ( still use C++ ). A lot of things I hated, I've come to like, and a lot of thigns I thought were issues turned out not to be. It's only now that I'm doing some C++ work again that I realise all the things C# does for me that I never really noticed, because at the time I was used to doing them myself in C++.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Hi Christian,
It really takes you that long to write a simple stored proc to do a data update ?
Well I am completely new to C# and .Net. I was hoping to at least get some simple data entry forms (against a SQL back-end) created to get a taste of it's capabilities. But it's turning out that I will have several days (weeks?) of study to even get to that level.
I would agree that the disconnection between the defaults you show and the defaults enforced by the DB can be a kludge, unless you don't have defaults in the DB and let the UI enforce them instead.
I think the user should (and would want to) see the default values for new table fields when they create a new record. Also, if a field can't be null, then the run-time environment complains even though a non-null default value is called for at the server side.
I had been hoping to dispense with the data-based data-dictionary that I have used over the years with my apps and to rely more on the properties, constraints, etc. recorded in SQL Server. But it's beginning to look like I'll still have to gain a fair level of knowledge about C# and implement several classes just to develop my applications' basic data maintenance processes.
And so, to curtail my complaints for now, I'll just say that I don't think MS has come as far as they should have with .Net..., given all their resources and their posturing. But enough talk for now. It's time to study up.
Thanks
Take Care,
Karl Kaiser
|
|
|
|
|
KarlKaiser wrote:
But it's turning out that I will have several days (weeks?) of study to even get to that level.
Possibly, depending on where you're coming from.
KarlKaiser wrote:
I think the user should (and would want to) see the default values for new table fields when they create a new record
Then do what I said - enforce defaults in the UI, not the DB.
KarlKaiser wrote:
But enough talk for now. It's time to study up.
Have fun....
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
It sounds to me like you've locked yourself into a product that, right or wrong, was bought by Microsoft for the express purpose of killing it.
Actually, Microsoft did a very good job with keeping FoxPro alive even though it was in competition with Access. Its only as we entered the .NET world where FoxPro started to get left behind as its language (being data-centric) couldn't be made compliant.
Michael
CP Blog [^] Development Blog [^]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
