|
Hi,
I used an object of class type derived from XmlTextReader which implemented IDisposable. What member function of XmlTextReader should I call to clean up so that I can call them in the Dispose function of my derived class. If I understand correctly I really should only call Close() but do I need to call other functions like for example Flush()?
Having implemented the IDisposable pattern, I can now use my object in the form
using(MyDerivedXmlTextReader _mdXml = new MyDerivedXmlTextReader(...))<br />
{...}<br />
TIA!
I am a SysAdmin, I battle my own daemons.
|
|
|
|
|
By wrapping the class in the using statement, the Dispose method is automatically being called when the using block ends. Generally (but not always), Close is synonymous with Dispose . You can verify that by looking at the MSDN docs or using Reflector to look at the code. The Flush method generally is used to flush any data in the internal buffer to disk. Again, generally, the Close method will typically call Flush .
|
|
|
|
|
Okay now my problem:
I want to have a program (for example form1) that holds a data structure
if i click on call, form1 loads dynamically another program (showform)
shoform needs to get to the data structure in form1 to view this sturct, but how??
sry for bad english ^^
|
|
|
|
|
|
Der M wrote: I want to have a program (for example form1) that holds a data structure
if i click on call, form1 loads dynamically another program (showform)
Do you really mean different programs, or only forms (in the same program)?
If you mean different forms, this[^] article will help you.
[ My Blog] "Visual studio desperately needs some performance improvements. It is sometimes almost as slow as eclipse." - Rüdiger Klaehn "Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfe
|
|
|
|
|
I mean diffrent Programs.
|
|
|
|
|
How would you suggest that I go about multiplications for decimal and double types since they are not allowed by VS2005?
I'm not sure why they are not allowed by Microsoft, but, is there some valid reason for that?
In the following snippet the code will break at the following line:
_balance += _amount + (amount * 0.1);
Error:
Error 1 Operator '*' cannot be applied to operands of type 'decimal' and 'double'
--------------------------------------------------------------------------------------------
Code:
using System;
using System.Collections.Generic;
using System.Text;
using Wrox.Interfaces;
using Wrox.Classes;
namespace Wrox.Interfaces
{ public interface IBankAccount
{
void PayIn(decimal amount);
bool Withdraw(decimal amount);
decimal Balance
{ get;}
}
}
namespace Wrox.Classes
{
public class VenusBankAccount : IBankAccount
{
public Exception InsufficientFunds;
private decimal _balance;
public void PayIn (decimal _amount) {
_balance += _amount;
}
public bool Withdraw (decimal _amount) {
if (_balance > _amount)
{
_balance -= _amount;
return true;
}
else
{
throw InsufficientFunds;
}
}
public decimal Balance {
get
{
return _balance;
}
}
public void PayInWithCommission (decimal _amount) {
_balance += _amount + (amount * 0.1);
}
}
}
namespace TestConsole
{
class Program
{
static void Main(string[] args)
{
IBankAccount myFirstBankAccount = new VenusBankAccount();
myFirstBankAccount.PayIn(1000);
VenusBankAccount myRealVenusBankAccount = new VenusBankAccount();
myRealVenusBankAccount.PayInWithCommission(1000);
}
}
}
Jon
|
|
|
|
|
You express a decimal literal as 0.1M if I recall correctly.
|
|
|
|
|
Try it like this:
_balance += _amount + (amount * 0.1m); The m (or M)tells the compiler to treat the number as a decimal value, without it the number is treated as a double .
The reason this is giving you an error is that there are no implicit conversions between floating-point types and the decimal type. A decimal denotes a 128-bit data type. Compared to floating-point types, the decimal type has a greater precision and a smaller range, which makes it suitable for financial and monetary calculations. The double keyword denotes a simple type that stores 64-bit floating-point values.
|
|
|
|
|
That is an excellent explanation.
|
|
|
|
|
|
Could someone point me in the direction of an article perhaps on how to write DLL's in C# and call them from C++ or Delphi or something other than a .NET language?
I'm hoping this is even possible?
Cheers
|
|
|
|
|
Dewald wrote: I'm hoping this is even possible?
Exposing the .NET assembly as either COM objects or Web Services would do that. Alternatively you can use C++/CLI to reference the C# managed assembly (DLL), wrap the .NET object API and expose a Native C++ or C API that non .NET languages can call. Based on the small amount of information you provided I would guess COM might be a good solution for you.
|
|
|
|
|
|
I have been programming in C# for years now, but I have never gotten a straight answer on this:
we always declare "using System.Whatever" at the top of a .cs file to make life easier when we program, but is there a cost associated with having many of them declared, especially (or even) if they arent used, or are they treated much the same as comments and they get stripped out during the compile if they arent used?
It's been bugging me for years.
______________________
Mr Griffin, eleventy billion is not a number...
|
|
|
|
|
Hello,
Look at this thread[^] and specially at "Guffa's" post!
All the best,
Martin
|
|
|
|
|
Awesome, thank you
______________________
Mr Griffin, eleventy billion is not a number...
|
|
|
|
|
From what I understand is that the using statements work the same as in C++ in the since you don't have to add the namespace to each command you are trying to use/call, but they have the added benefit of calling the garbage collector to look for those associated objects in your code. Makes is so you don't have to manually call dispose to it for the mem to be cleaned up during exit.
I guess there might be a *small* downfall to them but, I doubt it is worth messing with and isn't much faster than removing one IO write....
more info here: http://msdn2.microsoft.com/en-us/library/zhdeatwt(VS.80).aspx[^]
|
|
|
|
|
I think you're mixing the concepts. There are "using directives", which the OP is mistakenly calling "statements", that appear at the top of the code file and tell the compiler that you are "using" types out of the specified namespace.
The "using statements" are a type of syntax shorthand for wrapping an IDisposable type in a try/finally block. They are completely independent and separate from one another. The only commonality is that they, unfortunately, share the same keyword.
|
|
|
|
|
Correct, the C# Specification (section 9.3) calls them directives. I think much of the confusion is that they don't have a leading # like "normal" directives.
And, perhaps, many beginners don't learn the actual using statement, so they don't know the difference.
Plus, a lot of books confuse the issue; looking in three I have here:
"Professional C#" (Wrox), page 40, says, "using statement"
"Developing Web Applications" (Microsoft), page 93, says "using statement"
"C# for Dummies", page 331, says, "using command"
|
|
|
|
|
Yes...there is a lot of confusion around this. It would have been better to prefix them with the "#" or use a different keyword (like include or import). Unfortunately, I don't see this changing since it would break everything.
|
|
|
|
|
It makes life easier for you. Consider it shorthand. It doesnt affect your compiled code at all. (You'll be surprised how many different ways you can do things before it changes the IL).
|
|
|
|
|
No, they don't adversely affect the program; they simply save the programmer many many many keystrokes. And my opinion of them is pretty well documented in that other thread so I won't repeat myself yet again other than to say, "I don't use them".
On the other hand, most practitioners don't advance beyond the very simplest use of the using directive.
For instance, one could write
using System.Collections.Generic ;
...
Dictionary<string,object> mystuff = new Dictionary<string,object>() ;
Dictionary<string,object> yourstuff = new Dictionary<string,object>() ;
Dictionary<string,object> hisstuff = new Dictionary<string,object>() ;
but one could also write
using LookupTable=System.Collections.Generic.Dictionary<string,object> ;
...
LookupTable mystuff = new LookupTable() ;
LookupTable yourstuff = new LookupTable() ;
LookupTable hisstuff = new LookupTable() ;
which has the benefits of saving even more keystrokes, makes the program easier to maintain (the definition of LookupTable only needs to be changed in one place), and may just be better OOP.
(And less time replacing <s with <s when posting on CP!)
Another use for the using directive is this
using DatabaseConnection=System.Data.SqlClient.SqlConnection ;
using DatabaseCommand =System.Data.SqlClient.SqlCommand ;
using DatabaseReader =System.Data.SqlClient.SqlDataReader ;
using DatabaseParameter =System.Data.SqlClient.SqlParameter ;
using DatabaseAdapter =System.Data.SqlClient.SqlDataAdapter ;
...
then, if the underlying database technology changes, only the using directives need be modified; again, simplifying maintenance.
Taking that to the next level, we can make the selection of the actual database classes a compile-time issue
# if SqlClient
using DatabaseConnection=System.Data.SqlClient.SqlConnection ;
using DatabaseCommand =System.Data.SqlClient.SqlCommand ;
using DatabaseReader =System.Data.SqlClient.SqlDataReader ;
using DatabaseParameter =System.Data.SqlClient.SqlParameter ;
using DatabaseAdapter =System.Data.SqlClient.SqlDataAdapter ;
...
# endif
# if OleDb
...
# endif
# if MySql
...
# endif
...
The problem with this technique is that one must ensure that one and only one of the database systems is defined -- this is an unfortunate side-effect of Microsoft gutting the C preprocessor for use with C#.
Using the standard C preprocessor, one can write
# define SqlClient 1
# define OleDb 2
# define MySql 3
# define UseDatabase 1
# if (UseDatabase==SqlClient)
using DatabaseConnection=System.Data.SqlClient.SqlConnection ;
using DatabaseCommand =System.Data.SqlClient.SqlCommand ;
using DatabaseReader =System.Data.SqlClient.SqlDataReader ;
using DatabaseParameter =System.Data.SqlClient.SqlParameter ;
using DatabaseAdapter =System.Data.SqlClient.SqlDataAdapter ;
...
# endif
# if (UseDatabase==OleDb)
...
# endif
# if (UseDatabase==MySql)
...
# endif
|
|
|
|
|
Good explanation on the different ways to use the using directive. It is unfortunate that we don't have a bit more in the preprocessor to at least allow the #define statments.
|
|
|
|
|
Oh, and I left out the use of the using directive to write
using WinForms=System.Windows.Forms ;
using WebForms=System.Web.UI.WebControls ;
...
WinForms.Button b1 = new WinForms.Button() ;
WebForms.Button b2 = new WebForms.Button() ;
(But then, only I would be crazy enough to do that.)
|
|
|
|