|
rahul21 wrote: I am using connected architecture.
AFAIK, DataTable is not a connected architecture.
|
|
|
|
|
Hello!
Does anyone know how to send a ^ using the SendKeys class?
All other characters I tested work fine. ^ of course needs to be escaped using {^} (because ^ would press Ctrl), however when sending {^} it actually types a & ...
Best regards
Dominik
|
|
|
|
|
Hi,
noticed this on documentation:
If your application is intended for international use with a variety of keyboards, the use of Send could yield unpredictable results and should be avoided
while SendWait-method does not have this note.
Mika
|
|
|
|
|
Sorry, I should have pointed out that I'm already using the SendWait static method of the SendKeys class.
Any other idea?
Best regards
Dominik
|
|
|
|
|
If you change the keyboard layout to English, caret works just fine, but for example with Finnish layout, ampersand is sent instead caret (just like in your case). Since every other character works as expected, I would consider this as a possible bug.
Mika
|
|
|
|
|
Hi,
I'm creating a DAL for my project and I implemented IDisposable in my class because I wanted to dispose the SqlConnection object and SqlCommand object. The code goes like this:
public class CustomerDal:IDisposable
{
SqlConnection connection;
SqlCommand command;
private bool _IsDisposed = false;
public void Dispose()
{
Dispose(true);
}
protected virtual void Dispose(bool IsDisposing)
{
if (_IsDisposed)
return;
if (IsDisposing)
{
if (connection != null)
connection.Dispose();
if (command != null)
command.Dispose();
}
_IsDisposed = true;
}
}
during compilation, I get the error:
new protected member declared in sealed class
I dont use any unmanaged objects, so I need to dispose only connection and command object in this class. Could anyone help me with this error?
Regards,
Blumen
|
|
|
|
|
Blumen wrote: new protected member declared in sealed class
I dont use any unmanaged objects, so I need to dispose only connection and command object in this class. Could anyone help me with this error?
If you seal the class then you cannot inherit from it. If you cannot inherit from it then protected is a pointless access modifier to use. Use private instead of protected.
protected means that only members of this class (and any nested classes) and any class that inherits from it. private means only this class (and any nested classes).
Also, the virtual keyword is also pointless in a sealed class.
|
|
|
|
|
Thanks alot, making it private gets rid of the error.
But dispose is a method of base class, so is it okay to remove the virtual keyword?
|
|
|
|
|
Blumen wrote: But dispose is a method of base class, so is it okay to remove the virtual keyword?
The virtual keyword is supposed to go in the base class. In the derived class you override the method.
|
|
|
|
|
Does that mean I have to override dispose on my class like:
private override void Dispose(bool IsDisposing)
and make class sealed
modified on Sunday, August 17, 2008 9:05 AM
|
|
|
|
|
Blumen wrote: Does that mean I have to override dispose on my class
If Dispose(bool) exists in the base class then yes.
Blumen wrote: and make class sealed
Sealing the class is not necessary - It was something that you wanted to do already.
Sealing a class means that nothing can inherit from the sealed class. If that is what you want then seal the class. If that is not what you want, or if you don't know whether you will want to inherit from the class then don't seal it.
|
|
|
|
|
Thank you for your time, I appreciate you patience in answering my queries.
I'm planning to use my DAL class with ObjectDatasource control in ADO.NET 2.0. So will this control call my class's Dispose() ?
|
|
|
|
|
Blumen wrote: ObjectDatasource control in ADO.NET 2.0. So will this control call my class's Dispose()
I don't think so. Just put break points in the dispose method, or write some log entries in the dispose method to find out it calls dispose.
I don't know your whole DAL design, but from the code provided, I didn't find any use of implementing IDisposable here. You could dispose the command and connection after using it. Something like
public class CustomerDal
{
public void AddCustomer(...){
using(SqlConnection connection = new SqlConnection(...))
using(SqlCommand command = new SqlCommand(connection,...)){
}
}
}. This ensures dispose of connection and command gets called after using it.
|
|
|
|
|
The reason why I implemented IDisposable is because i ran my dll in FxCop and it suggested me to use IDisposable because I was using SqlConnection and SqlCommand objects.
|
|
|
|
|
This is the whole problem with FxCop (and utility's like it). They give broad brush guidelines that people tend to end up as treating as gospel. This suggestion only makes sense if your SqlConnection/SqlCommand objects are member variables. If they are a local variable then there is no sense in using IDisposable to manage this.
|
|
|
|
|
Pete O'Hanlon wrote: They give broad brush guidelines that people tend to end up as treating as gospel.
I don't, so I must be a rebel 
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
Pete O'Hanlon wrote: This is the whole problem with FxCop (and utility's like it). They give broad brush guidelines that people tend to end up as treating as gospel.
While that is generally true, FxCop does provide some very solid guidelines. The end result is that it should be up to the developer/development team/... to decidd which guidelines are appropriate. I know that isn't always the case, but that's the idea behind these types of tools. They also help people learn the right way to do the majority of things in .NET.
Pete O'Hanlon wrote: This suggestion only makes sense if your SqlConnection/SqlCommand objects are member variables.
Based on the sample code in the original message, this is the case so the guideline is accurate.
Pete O'Hanlon wrote: If they are a local variable then there is no sense in using IDisposable to manage this.
Very true and if that were the case, FxCop never would have flagged this issue.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
Correct. It told you that because you are declaring your SqlConnection and SqlCommand variables as class-wide variables. In that case, you do need to implement IDisposable.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
Blumen wrote: Does that mean I have to override dispose on my class like:
If your class is inherited from another class which implements IDisposable and uses dispose pattern, then you have to override the virtual method provided. If your class is the one which implements IDisposable and you want to make it as sealed, don't use the dispose pattern at all. Just write cleanup in the dispose method provided by the IDisposable interface.
You use dispose pattern if you need to allow subclasses also to do cleanup. Example is "Stream".
Scott dorman has a great article[^] on the subject. It's worth reading.
|
|
|
|
|
Yes, my class implements IDisposable interface. I'll refer the article you have provided, thank you.
|
|
|
|
|
N a v a n e e t h wrote: Scott dorman has a great article[^] on the subject. It's worth reading.
Thanks!
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
The code you show doesn't match your error message. Your code does not show the CustomerDal as a sealed class.
For more information on the Dispose pattern, check out this article[^].
If you are going to seal the class, then you can't declare protected methods (or properties). Sealing tells the compiler that nothing can inherit from that class; since protected means that only that class and any derived class can access it, protected methods are effectively useless. As Colin pointed out, making the method private would work.
If you really want to seal your class, then you only need to implement the IDisposable interface, not the full Dispose pattern. In your sample code, the logic you have in the Dispose(bool) method would simply go in the Dispose() method, which would be the only method you need to implement.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
The reason why I thought of sealing my Data Access class in the first place is because it is not meant to be a base class. It just contains a few Methods calls that fetch data from database or write/edit data (queries basically).
Thanks to all who have replied to my query here. I hope this code is correct:
public sealed class CustomerDal:IDisposable
{
SqlConnection connection;
SqlCommand command;
public void Dispose()
{
if (connection != null)
connection.Dispose();
if (command != null)
command.Dispose();
}
}
Could anyone point me to a resource where I can find a DAL class which is provider independent, which supports transaction as well in C# 2.0?
Regards,
Blumen
|
|
|
|
|
Blumen wrote: Could anyone point me to a resource where I can find a DAL class which is provider independent, which supports transaction as well in C# 2.0?
NHibernate or Castle ActiveRecord both fit the bill here (although strictly speaking they are more ORM and ActiveRecord builds on top of NHibernate).
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
