|
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 [^]
|
|
|
|
|
Hi,
I have been looking into implementing SHA-2 Hashing into my application, but I am unsure if it is available in the .NET Framework. I have read conflicting info on the Net; some says that the SHA256, 384 and 512 are different bit strenght versions of SHA-1 and some say SHA-2. If not does anyone have a C# implementation of SHA-2?
Thanx!
Dave Shaw
History admires the wise, but elevates the brave. - Edmund Morris
|
|
|
|
|
Dave,
Have you read the article Good Bye MD5 by ediazc here on Code Project? It may point you in the direction you want to go.
Paul
|
|
|
|
|
There appears to be a bug in the Region.Union function in GDI+. I see this in programs developed in C# .Net using Visual Studio 2003. I have been using Regions in an application I have been developing and in most cases have had no problems with the Union function. I noticed some occasional glitches in my program and have traced them to this bug in Microsoft's routine. The Union function allows you to build up various shapes/regions together into a region encompassing all the subparts. In the example below I create a Region that is the combination of 3 rectangles. The fact that the rectangles overlap may be what triggers the bug, although the function should be able to work with overlapping areas.
If anyone can prove me wrong I'll be very impressed.
The problem can be demonstrated in this simple test code which responds to the paint event. To run the code, create a C# windows forms application. And put this code in your paint event handler.
The code will draw the outlines of the three rectangles with a black dashed line. The pink area should be the combination/union of the areas of the 3 rectangles. You'll see there is a small area missing that should be filled in pink but its not.
I wasn't able to find anything on the internet regarding this bug so I thought I would post it.
<br />
private void Form1_Paint(object sender, System.Windows.Forms.PaintEventArgs e)<br />
{<br />
Rectangle rect1,rect2,rect3;<br />
rect1 = new Rectangle(435,235,50,50);
rect2 = new Rectangle(180,80,250,250);
rect3 = new Rectangle(335,135,250,250);
<br />
Region redrawRegion = new Region();<br />
redrawRegion.MakeEmpty();<br />
redrawRegion.Union(rect1);<br />
redrawRegion.Union(rect2);<br />
redrawRegion.Union(rect3);<br />
using(Brush myBrush = new SolidBrush(Color.Fuchsia))<br />
{<br />
e.Graphics.FillRegion(myBrush,redrawRegion);<br />
}<br />
<br />
using(Pen myPen = new Pen(Color.Black))<br />
{<br />
myPen.DashStyle = System.Drawing.Drawing2D.DashStyle.Dash;<br />
e.Graphics.DrawRectangle(myPen,rect1);<br />
e.Graphics.DrawRectangle(myPen,rect2);<br />
e.Graphics.DrawRectangle(myPen,rect3);<br />
}<br />
}
Any suggestions or comments are welcome.
Steve Knauber
|
|
|
|
|
Hi!
Last week I could play a little bit with Axapta from Microsoft.
I didnt like the GUI and Navigation but I wonder how to build an application
with 7 customizable layers. IMHO SAP or PeopleSoft are similar ? (Country, Industry, partner, Custpomer,..) where each can be edited and
they can still use the same core libraries and businessfunctions ?
How do they do this ? Can anyone pass me links or give me some information how to build such applications ? Maybe just with two layers. Do they use plugins or subclassing ?
Thanks Thomas
|
|
|
|
|
|
I want to call HtmlHelp API function. I include the .h file and specify the incluce and libary directories. Howerver, it continuous give this error "error C2660: 'CWnd::HtmlHelpA' : function does not take 4 arguments".
|
|
|
|
|
I have a C# windows service that depends on time comparisons that is encountering problems due to the time zone on the machine being changed. Unfortunately, this time zone change is outside of my control. I use the TimeZone.CurrentTimeZone.ToUniversalTime() and TimeZone.CurrentTimeZone.GetUtcOffset() methods to make sure all my times are converted and compared as UTC. The problem is that TimeZone.CurrentTimeZone is not updating when the machine's time zone has changed. You can reproduce this easily by creating a console app with the following lines of code, and manually changing your machine's time zone during the app's pause.
Console.WriteLine("Current time zone is {0}.", TimeZone.CurrentTimeZone.StandardName);<br />
Console.Write("Waiting for time zone change. Hit 'Enter' to continue ...");<br />
Console.ReadLine();
Console.WriteLine("Current time zone is {0}.", TimeZone.CurrentTimeZone.StandardName);
Does anyone have any idea about how to refresh or update the TimeZone.CurrentTimeZone? Thanks!
|
|
|
|
|
I think I found a work-around, but I don't fully like it. If I call the GetSystemTime WinAPI function, it seems to always return the correct UTC time.
I got some decent sample code from Anson Goldade's GotDotNet user sample to nicely encapsulate the API calls. Too bad Microsoft's framework methods don't call the API correctly.
|
|
|
|
|
The problem is that the CurrentTimeZone property caches the result for the lifetime of the AppDomain, so you won't see any changes until your AppDomain is restarted.
The simplest option is to use reflection to create a new instance of the internal CurrentSystemTimeZone class. The following code will cache the current time zone for 5 minutes, and allow you to manually refresh the time zone as well:
using System;
using System.Reflection;
public sealed class CurrentTimeZone
{
private const int RefreshAfterMinutes = 5;
private static readonly object _lockMe = new object();
private static readonly Type _timeZoneType;
private static readonly ConstructorInfo _timeZoneConstructor;
private static TimeZone _instance = TimeZone.CurrentTimeZone;
private static DateTime _instanceCreated = DateTime.UtcNow;
static CurrentTimeZone()
{
_timeZoneType = TimeZone.CurrentTimeZone.GetType();
_timeZoneConstructor = _timeZoneType.GetConstructor(
BindingFlags.Instance | BindingFlags.NonPublic,
null, new Type[0], null);
}
private static TimeZone CreateInstance()
{
return (TimeZone)_timeZoneConstructor.Invoke(null);
}
private static void UpdateIfStale()
{
TimeSpan age = _instanceCreated - DateTime.UtcNow;
if (age.TotalMinutes > RefreshAfterMinutes)
{
_instance = CreateInstance();
_instanceCreated = DateTime.UtcNow;
}
}
public static TimeZone Instance
{
get
{
lock(_lockMe)
{
UpdateIfStale();
return _instance;
}
}
}
public static void Refresh()
{
lock(_lockMe)
{
_instance = CreateInstance();
_instanceCreated = DateTime.UtcNow;
}
}
}
All you need to do is replace each instance of TimeZone.CurrentTimeZone with CurrentTimeZone.Instance, and you should see the changes within 5 minutes.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
|
|
|
|
|
Unfortunately, I need to know the time zone at the exact moment that the code runs, and even 5 minutes late could cause issues.
Anyway, while it's pretty cool, do you really think that your class is the simplest way to fix the problem when you can just call the GetSystemTime API?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
