|
Thank you for your answer. I guess the dictionary solution is the only one I have to address this issue. In case a user wants to add a type of class that is not contained in my collection I will let him/her to add the appropiate namespace to the dictionary .Is there a faster way than reflection to find out if the namespace is correct?
|
|
|
|
|
Is there a faster way than reflection to find out if the namespace is correct?
Not as far as I know. And it would be expensive: you would have to create
a separate AppDomain I guess, then try to list all DLL candidates, load them
(either all at once, exhausting memory, or one at the time; removing it is
only possible by unloading the AppDomain).
Warning: even the Dictionary approach is just an approximation; if there
were only one Timer (say Timers.Timer) and you added it to the dictionary,
now the next .NET release adds a second Timer (say Threading.Timer), your dictionary
would not know it, and enforce one kind of Timer, whereas the user might want
another one.
So my guess is:
1) you should not even try to do the massive reflection at run-time (you might
do it once to generate a dictionary)
2) I would generate a very small dictionary manually; it suffices to recognize
a couple of the most popular classes for each DLL (e.g. File, FileStream,
FileInfo, Directory is all I would recognize to include System.IO), there is
no need to have an exhaustive list
3) whatever you do, it will only be an attempt, good enough to provide
an initial source file, not good enough for generating a ready-made and
error-free source file.
BTW: Actually, when I said Dictionary, that is not strictly correct, since
classnames are not unique (Timer example again).
|
|
|
|
|
That's what I was affraid off....
|
|
|
|
|
I have an idea. I don't know if it is a good one but here it goes...
What if I try to instantiate an object of that type inside a using directive (using the namespace provided), catch the exception if it appears and notify the user...or by using System.Type.GetType() in some way...
|
|
|
|
|
There are only two ways to instantiate a class:
- the normal way, with the new keyword; it implies you have compiled correct code
hence you already have the necessary using statement (and the reference in your
project);
- the reflective way, which means you load some assembly, locate the class,
and invoke its constructor; hence you must know which assembly to load; if you do,
you also know which using is required !
So the only thing that you can do is collect the source lines, add using statements
as much as you see fit, then try to compile and present (a summary of) the error
messages to the user.
|
|
|
|
|
Ehhh..I was worth the shot
|
|
|
|
|
If the user is specifying the members/methods/properties why not also let them specify the Using directives to use?
Or alterntively make them fully specify any types used (in this case System.Collections.ArrayList) which would negate the need to have using directives at all.
|
|
|
|
|
Don't use using directives.
|
|
|
|
|
I need using directives because I want to give my newly created class that is included in a given project a chance that it will compile. I don't want to let the user crash a good project with some typos or something. I think I will go with the suggestion of forcing the user to select a given type. Probably I will implement somekind of intellisense.
|
|
|
|
|
You never need using directives; they are crutches for weak programmers.
|
|
|
|
|
PIEBALDconsult I don't think you understant what am I doing. I am generating a C# code file (*.cs) row by row. Of course I need using directives when I start writing like, for example
"using System;". I don't intend to write using directives in any of the methods code.
|
|
|
|
|
Right, don't do that, write out the full name of everything.
|
|
|
|
|
HI,
I have a List<showchartviewen> where I added values as in order A,B,C,D
but while using dataGriDview1.DataSource= scvn;//Scvn is an object of the List<>
But in the dataGridView the order is comin different.
And I want the order I have added.
Help me
|
|
|
|
|
dataGriDview1.AllowSorting = false;
|
|
|
|
|
Hi,
If this is the wrong forum please guide me to the correct one, I didn't know where to post it.
Yesterday I started doing unit testing with NUnit and XNA (the successor of Managed DirectX).
While everything works fine inside Visual Studio and from Windows Explorer, I get the following Exception when running my tests from the NUnit GUI:
GameStateManagement.TestClass.TestScreenModeManager : Microsoft.Xna.Framework.Content.ContentLoadException : Error loading "menufont". File not found.
----> System.IO.DirectoryNotFoundException : A part of the path C:\WINDOWS\assembly\GAC_32\Microsoft.Xna.Framework\1.0.0.0__6d5c3888ef60e27d\Content\menufont.xnb could not be found.
Content\ is a subfolder relative to my project, which gets accessed correctly in VS and Explorer.
But the NUnit GUI seems to set my absolute executable folder to C:\WINDOWS\assembly\GAC_32\Microsoft.Xna.Framework\1.0.0.0__6d5c3888ef60e27d\ which makes absolutely no sense to me. I actually should be the project folder, like C:\C#\Projects\...\
Does anyone know what I am doing wrong here?
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
I want to convert my .doc file to .pdf file without any third party tools or dlls.(I am using ASP.NET 2.0 with language C#)
let me know you suggestions ?
Thanks in advance
adil kazmi
|
|
|
|
|
you do realise PDF conversion is not natively supported in .NET and you do need to resort to using 3rd party dlls/tools. If you want native support for some type of document generation than skip pdf and start using XPS. XPS is supported by WPF in .NET 3.0/3.5.
|
|
|
|
|
|
Today, I stumbled on the strangest behavior I've seen so far and unfortunatley I'm not able to find an explaination. Here is the problem:
I'm currently testing a library with random generators. The generators have a function NextDouble that generates a floating point random number within a specified range. The range is computed by subtracting the specified minValue from the specified maxValue. Afterwards the computed range is passed to double.IsPositiveInfinity, so the method can throw an exception if an overflow occured.
Strangely the comparison only works in Debug mode (below code outputs "NextDouble: Infinity"). If I run the same code in Release mode the comparison does not work (below code outputs "NextDouble: Not infinity"). I first thought this might be an issue of code optimization, but even if I turn off the optimization in release mode it doesn't work. To make the whole thing even more strange, the comparison works if the final Console.Out is uncommented.
Does the small console application show the same behavior on your computers? Does someone have an explaination for this strange behavior? By the way, I'm running this with .NET framework 2.0.50727.
static class Program
{
[STAThread]
static void Main()
{
NextDouble(Double.MinValue, Double.MaxValue);
Console.ReadLine();
}
public static void NextDouble(double minValue, double maxValue)
{
double range = maxValue - minValue;
if (double.IsPositiveInfinity(range))
Console.Out.WriteLine("NextDouble: Infinity");
else
Console.Out.WriteLine("NextDouble: Not infinity");
}
}
-- modified at 9:11 Tuesday 31st July, 2007
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." - Rick Cook www.troschuetz.de
|
|
|
|
|
Did you read the documentation ?
on Double.PositiveInfinity MSDN gives the remark:
Use IsPositiveInfinity to determine whether a value evaluates to positive infinity. It is not possible to determine whether a value evaluates to positive infinity by comparing it to another value equal to PositiveInfinity
I don't know about different handling of extreme double values under debug/release
conditions; as long as you go against the manual, you can't trust the behavior
anyway.
|
|
|
|
|
I forgot to mentioned that I suspected something like this too and also tested with Double.IsPositiveInfinity . The behavior is the same, so I didn't took a look at the documentation of Double.PositiveInfinity .
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." - Rick Cook www.troschuetz.de
|
|
|
|
|
Stefan Troschuetz wrote: so I didn't took a look at the documentation
There is no excuse; you should read the documentation before using something.
And you should consult it again as soon as you don't agree with the observed
behavior of it.
In the end, that is only after after careful reading and analysis, you can
start publishing messages with "strange behavior" in their subject...
|
|
|
|
|
Ok, normally I read the docs very carefully. In this case I must admit that I only read the documentation of Double.IsPositiveInfinity , since after I changed range == double.PositiveInfinity to double.IsPositiveInfinity(range) and the behavior staid the same I jumped to the conclusion that it is not a matter of doing a comparison against Double.PositiveInfinity . You're right that it is no good excuse (especially not for using Double.PositiveInfinity in the first place), but the there is still the strange behavior of Double.IsPositiveInfinity .
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." - Rick Cook www.troschuetz.de
|
|
|
|
|
Stefan Troschuetz wrote: I read the docs very carefully
Your modified code runs fine for me; it gives "Infinity"
when running in debug under Visual 2005
when running in release under Visual 2005
and when running outside Visual 2005
|
|
|
|
|
I was afraid of something like this. It still does not work on my computer neither under VS2005 nor outside. The same result on my laptop. Maybe this is an issue of the german version only
Tested the code under framework 1.0 and 1.1 and there it runs just fine. Also I took a look at the IL code and could not find an obvious error though I must admit that I have not much experience with IL.
I'm somewhat out of ideas what to do with this
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." - Rick Cook www.troschuetz.de
|
|
|
|