|
What Christian is talking about is an overload:
void DataAccess(int x, float y)
{
DataAccess(x, y, DateTime.MinValue);
}
void DataAccess(int x, float y, DateTime actualDate)
{
}Since DateTime is a value type it cannot be null. It is fairly common, however, to use DateTime.MinValue to represent an invalid date since you will most likely not need to reference Midnight, Jan 1., 0001.
To note, in .NET 2.0 a new generic type - Nullable - is introduced for these particular problems. This would allow you to declare your method like so:
void DataAccess(int x, float y, Nullable<DateTime> actualDate)
{
}You can also replace Nullable<DateTime> with DateTime? (notice the question mark). To make the parameter optional, however, you still need to overload the method.
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Thanks for you time and help
I removed the fields that it will be enter later from the method and marke this fields as Allow null in sql server and it workd fine.
and when i want to enter this fields later i will edite this tbl with the new value
is this right?
hay
|
|
|
|
|
Yes, if you don't want to input a data all the time, that sounds great.
Perhaps a seperate 'SetDate' method is what you need, or just a general update method that can take a date as one field to change.
Christian
I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
|
|
|
|
|
I'm trying to create a dragging data cursor that can be dragged horizontally on an xy plotted graph. Currently, every time the cursor gets dragged, i have to redraw the entire plotted graph. Is there any way to simply redraw the cursor in its new position without redrawing the entire graph. The graph is currently created as a user control and the cursor is simply a line drawn in the control.
thanks
|
|
|
|
|
If you are responsible for drawing the graph then you need to take care to only draw the area specified in PaintEventArgs.ClipRectangle, which is the invalidated area of your control. The whole graph does not need to be repainted unless, of course, the clipping area covers the entire control.
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Does anyone know how program the Serial Port i.e. inizilization, read, and write in C#. I'm having some problems figuring this one out.
Thanks
mci84078
bryan@wilkinsbus.com
|
|
|
|
|
Although it may not help I just thought I'd mention that there is a new RS232 control in Visual Studio 2005. If you're able to develop using the beta version of VS.NET it may help.
|
|
|
|
|
Hi guys.
Assume I have the following situation.
I have two forms. Form1 and Form2. Both form has the same namespace.
And in Form1, I have a Panel1 control and a button1 control.
So when I click on button1 control, I want to add Form2 to Panel1.
For example sake:-
Instantiate it from Form1.
Form2 frm2 = new Form2();
Panel1.Controls.Add(frm2);
Now, at run-time, when i click on Button1 to instantiate those codes, I get, the following error msg...
"Cannot add a top level control to a control". Anyways around this ?
Stanley
|
|
|
|
|
You can't add a windows form onto a control like that. You can, however, create a user control and add it onto your panel. That might be what you're looking for...
|
|
|
|
|
jbx1828 wrote:
And in Form1, I have a Panel1 control and a button1 control.
So when I click on button1 control, I want to add Form2 to Panel1.
You've got to set the Form.TopLevel[^] property to false and the Control.Visible[^] property to true.
Form2 myForm = new Form2();
myForm.TopLevel = false;
myForm.Visible = true;
panel1.Controls.Add(myForm);
I think the effect is kind of weird. So just out of curiosity: what kind of application are you writing?
Best regards
Dennis
|
|
|
|
|
Thanks a lot Dennis.
It works.
See, I have integrated UIPAB v2.0 block into it.
And somehow it uses views to navigate between forms (part of the UIPAB framework). Learning something new everyday.
Stanley
|
|
|
|
|
sir,
i want to enable/disable user accounts in active directory using c#.net.
please help me
|
|
|
|
|
Hello All, I am pretty stumped on this one... Basically I created a database application that has a Crystal Reports Viewer as a feature, my viewer works and everything in my app runs fine, after my first deployment (with one crystal report created), the need for other reports came about. My problem is that I am now no longer able to open, create or modify a crystal report in Visual Studios 2003. In the solution explorer, it shows the report, but when I double click it or try to open it, I get a "Specified Module Could Not Be Found" error. Thats it???? I have been looking and looking and cant seem find anything... I think maybe a dll or merge module or something could have gotten corrupted or is missing, but, I have no idea where to begin... Any help would be appreciated...
Thanks,
Brandon
|
|
|
|
|
|
Having developed C++ with Visual Studio 6.0 for many years, I have just moved to C# and Visual Studio .NET 2003. Much to my disappointment, I have found no similar feature to the "source browser", specifically the features "base classes and members", "derived classes and member", "call graph", and "callers graph". These are invaluable tools when looking into and understanding new code.
My question is now, is there some way I can get what I want? Is there a feature hidden somewhere where I haven't found it, or is there some external tool that can do this? "Derived classes" and "callers graph" are considered most important.
Thanks for any suggestions!
************************
Peter Andersson
|
|
|
|
|
There's many ways, and some of which are included in VS.NET. There's the Object Browser which you can access from the View menu, as well as the Class View similar to the original Class View for VC++ (and works the same as VC++, which several enhancements). If you want to see the IL for a module or modules within your assembly, you can open your assembly in ildasm.exe that ships with the .NET Framework SDK, which is installed by default with VS.NET (under the program folder for VS.NET typically called FrameworkSDK).
There's also third-party controls like .NET Reflector[^] that can disassemble and decompile managed code, as well as generate callee graphs.
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Thanks for your suggestion, but I dont believe the Object Browser and Class View even do 10% of what I want.
In VS6, I could very quickly see which classes are derived from any other class (current project/BSC-file only of course). This particular feature is very useful when trying to grasp the complexity of a new software library for example. I got some 20K lines of undocumented code in my lap today and this feature alone would cut days from the time needed to learn the existing code.
Agreed, the BSC files had drawbacks, only beeing updated when compiling, could only use one at a time etc, but I still believe it was a better technology than the current.
Class View and Object Browser seems to me be doing the same thing, at least regarding my own code, and that is to show the base classes and the members, and that is all and well in itself, but not nearly enough.
HOWEVER, now that I am done complaining and have stated that things were better in the goold ol' days, I must say that the .NET Reflector does what I need. Its a little cumbersome to use, but I can live with that.
Thanks alot for pointing out this great tool for me!
(Now maybe you could suggest a good tool that draws class hierarchies too?  )
************************
Peter Andersson
|
|
|
|
|
Hello All,
Quick question, i dont seem to beable to get the file.exists to work with a file that sits on a networked path. Ive triple checked the path. Now I am running this from an asp.net webservice, would I need to set up security for the asp.net user in the folder where the file exists on the network to get this to work properly?
Thanks!
Ryan
|
|
|
|
|
Yes File.Exists works on UNC paths and yes you have to grant permissions on that directory to whatever user context is running your code (or impersonate another user who already has permissions).
The ASPNET (the default account for ASP.NET) won't typically work, however, because it's a local user account. You need to either grant read permissions on the parent directory to Everyone (not necessarily List permissions, though) or change your machine.config file or the Web.config file in the application root to use a domain user account and password (be sure that you secure the Web.config file and don't index it if you configure the user in that file.
Depending on what you're doing, you could also impersonate whatever user is making the request by setting the <identity> configuration element data correctly (see the SDK documentation) and using NTLM authentication on the directory with no anonymous login enabled. There is documentation about how to do this in the .NET Framework SDK along with the documentation for the <identity> configuration element. If you're familiar with IIS and configuring ASP.NET this is not a problem.
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Hi!
I'm writing a wrapper assembly for an interop assembly that's not very nicely implemented. The interop is wrapping a COM object that was primarily meant to work with VBScript, and many methods return untyped values, although they could indeed return them typed.
Almost all classes in the assembly have the following structure
<br />
<br />
internal interface IBaseObject<br />
{<br />
object baseobject{get;}<br />
}<br />
<br />
public class WrappedSomething : IBaseObject<br />
{<br />
private InteropSomething _baseobject; <br />
public WrappedSomething(InteropSomething baseObject)<br />
{<br />
_baseobject=baseObject;<br />
}<br />
public object baseobject<br />
{<br />
get{return _baseobject;}<br />
}<br />
}<br />
The IBaseObjct interface is there to make it easy to pass these wrapped objects around inside the assembly, and give easy access to the wrapped object.
Of course this works just fine, but I don't like the fact that the classes exposes the property baseobject publicly. I don't want to give other assemblies access to the wrapped object. At least not as easily as it becomes when the property is public.
I could of course solve it by inheriting an internal class, but quite a few of the classes benifits greatly from inheriting other common (publi) functionality from other classes, and since there is no multiple inheritance....
Any suggestions?
Wouldn't is be viable to have the option to implement internal interfaces' methods internal only?
<br />
internal interface ISomething<br />
{<br />
int DoInternalStuff();<br />
}<br />
<br />
public class Dog : ISomething<br />
{<br />
internal int DoInternalStuff()<br />
{<br />
}<br />
}<br />
Since the interface is internal, I can't see any problem with declaring the implementing methods internal as well.
|
|
|
|
|
|
Thanks, I thought I had tried that, but obviously I hadn't..
However, it's not quite there yet.
If i use
<br />
object IBaseObject.baseobject<br />
{<br />
get{return _baseobject;}<br />
}<br />
I can't access baseobject directly. E.g
<br />
public void DoStuff(Dog Victim)<br />
{<br />
DoInteropStuff(Victim.baseobject);<br />
} <br />
This results in :
'Dog' does not contain a definition for 'baseobject'
Instead I have to write
<br />
public void DoStuff(Dog Victim)<br />
{<br />
DoInteropStuff(((IBaseObject)Victim).baseobject);<br />
} <br />
And, although I'm not sure, it seems that could lead to undesirable boxing/unboxing. Maybe it doesn't. I also find it strange that baseobject now becomes effectively internal, but I can't expose it as being internal.
|
|
|
|
|
emission wrote:
And, although I'm not sure, it seems that could lead to undesirable boxing/unboxing. Maybe it doesn't. I also find it strange that baseobject now becomes effectively internal, but I can't expose it as being internal.
Boxing and unboxing[^] describes the process where value types (eg, structs, primitives, and enumerations) are wrapped in objects or vice versa, basically. Read the link for more details.
Unless Victim is a value type (highly unlikely, especially in COM) there is no risk of boxing or unboxing - only conversion.
If you want to truly limit assembly access to a member or class, then learn to utilize the security infrastructure of .NET: Code Access Security[^].
If you want to limit access to a single assembly, you would attribute your member like so (declaritive security):
[StrongNameIdentityPermission(SecurityAction.Demand, Name="MyAssembly", PublicKey="0123456789abcdef")]
object baseobject
{
get { return _baseobject; }
}Where Name is your assembly name and PublicKey is your hex-encoded, 16-character public key (which you can get for your assembly in many ways). If you do not strong name your assembly than you have no security. The public key token is derived from your private key used to sign the assembly. If you don't sign the assembly and don't keep your private key private then anyone can spoof your permission demand.
If you want to allow all your assemblies access to the member, then just specify the PublicKey field and use the same key to sign all your assemblies (this is typical for a single organization anyway).
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
Thank you for enlightening me on the boxing issue. Now I know what that means.
Is there no overhead when converting, i.e using ((IBaseObject)Dog).baseobject instead of directly accessing a public Dog.baseobject?
Heath Stewart wrote:
If you want to truly limit assembly access to a member or class, then learn to utilize the security infrastructure of .NET: Code Access Security
Yes, I've studied this issue, after reading an article in MSDN Magazine, and this may very well be of interest in some projects. However, this time it's more a design issue than a security issue, and I just curiously wonder about the reasons behind.
I think that it would be logical that with interface
<br />
internal interface IAnimal<br />
{<br />
int Age{get;}<br />
}<br />
...a class like this
<br />
public class Dog : IAnimal<br />
{<br />
internal int IAnimal.Age<br />
{<br />
get {return 1};<br />
}<br />
}<br />
..would be quite enough to satisfy the interface contract. In fact I think it satifies the contract more clearly than
<br />
public class Dog : IAnimal<br />
{<br />
int IAnimal.Age<br />
{<br />
get {return 1};<br />
}<br />
}<br />
...does.
Since I'm obviously wrong I would like to be corrected, so that I can understand the reasoning behind this.
|
|
|
|
|
emission wrote:
Is there no overhead when converting, i.e using ((IBaseObject)Dog).baseobject instead of directly accessing a public Dog.baseobject?
Negligable. A cast is an instruction that must be processed but compared to boxing operations these are trivial.
emission wrote:
However, this time it's more a design issue than a security issue, and I just curiously wonder about the reasons behind.
No one said that CAS has to be used only for security. Even the term "security" is rather loose. If security means that you don't want other developers via their assemblies to "see" or even access the member than CAS is what you want. Even with explicit interface implementations (i.e., what you're currently doing) a coder merely has to cast to the interface. Even if you used the BrowsableAttribute or EditorVisibilityAttribute you're only hiding it. The only way to truly deny access to the member is CAS.
In .NET 2.0 a new attribute - InternalsVisibleToAttribute[^] - allows compilers to compile code that accesses internal members from another assembly.
emission wrote:
internal int IAnimal.Age
That would be a voilation. Besides, when you compile this the member is actually private, much more strict than your internal access modifier. The thing is that your object must be cast to an interface object on which the member is truly called, which must be public. The interface object references your object, however, so your private member is not access directly.
You can learn more about implicit and explicit interfaces at http://msdn.microsoft.com/library/en-us/csspec/html/vclrfcsharpspec_13_4_1.asp[^] (C# Language Specification).
This posting is provided "AS IS" with no warranties, and confers no rights.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles] [My Blog]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
