|
Something like this should work:
class SomeType
{
public void Foo()
{
Console.WriteLine("SomeType.Foo");
}
}
class AnotherType
{
private SomeType someType = new SomeType();
}
class App
{
static void Main()
{
AnotherType another = new AnotherType();
string fieldName = "someType";
FieldInfo fi = another.GetType().GetField(fieldName, BindingFlags.NonPublic | BindingFlags.Instance);
object fieldValue = fi.GetValue(another);
SomeType someType = fieldValue as SomeType;
if(someType != null)
{
someType.Foo();
}
}
}
|
|
|
|
|
Works perfect! Exactly what I´m searching for.
Thanks.
Regards
|
|
|
|
|
I've just spent a few days creating a User Control in a library, and for a project I want several similar controls. The new controls will contain some of the same elements, in different positions perhaps, and with different names, but the overall User Controls should be of the same size, color, font, etc.
Is there an easier way than manually creating each User Control and adding back all the elements, just to make something almost, but not quite identical to the original?
[EDIT]
I opened the project folder, located the three basic files for the control - .cs, .resx, .Designer - and copied them to a subfolder. I then renamed them and copied them back to the original project folder. Then I used Add Existing Item in VS to locate the renamed files and add them to my project. It choked, of course, because of ambiguity. Using Find and Replace, I opened all the new files, closed all the files I wanted to keep, and selected the option to Find and Replace in all open files, using the original filename and new file name as arguments. It worked like a charm, and will save me hours of manual editing. It even builds without error...
[/EDIT]
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
A good user control is like an onion...
But seriously, make a user control with the basic shape and colour and then specialize from that.
|
|
|
|
|
I have, but now I want to duplicate it several times within the project, but using different names for each copy. I'm thinking I might be able to get away with building the project now, then adding "existing items" from the project folder and giving them new names. Will that work?
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Sounds dreadful... maybe you're looking implants[^].
|
|
|
|
|
Your Implant idea is excellent, but I've already done what I added to the original post. Easy stuff, and no tedious retyping. Change the text in the labels, drag 'em around a bit, file off the serial numbers and, voila! A new control is born.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
I have a treeview that I populate with data from various tables in mysql db. I also update the tables based on user actions. I was wondering, is it more efficient to use a mysqlDataAdapter for this or just CommandText and MySql Reader for populating and then separate CommandText statements for updating?
|
|
|
|
|
A reader done right is usually, almost always, faster than a data adapter, dataset solution. In the cases where timings show a data adapter executing faster there is usually a flaw in logic. Where the Data Adapter and data set solutions are usually faster is in Dev/Time not run time.
|
|
|
|
|
|
While I wasn't looking for an answer to that question, it will certainly come in handy for a project I'm working on - one of several. Thanks!
Is not a reader a one-way solution, though; that is, for reading from a database in one direction? And a data adapter is more of a random access solution? Such additional overhead would certainly explain the performance difference.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
A common misconception. ADO.NET is exclusively a fast-forward, read-only cursor. The data adapter uses a data reader behind the scenes to get the data. What the data adapter does is attempt to infer the schema from the available result sets and then read to the end of all cursors populating a data set. You then get your data in a handy data set with associated overhead.
AFAIK there is not an ADO.NET solution intended to maintain an open cursor to the DB at all.
|
|
|
|
|
with associated unnecessary overhead
|
|
|
|
|
Back to the books...
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
DataReaders underly all ADO.net access; including ExecuteScalar, ExecuteNonQuery, and DataAdapter.Fill and .Update
Learning to use them effectively will make you a better developer. And chicks dig it.
|
|
|
|
|
PIEBALDconsult wrote: And chicks dig it
Well, that's good enough for me!
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Avoid DataAdapters for real work; their only purpose is to allow MS demonstrators at launch events to produce a barely-working program in the time allowed.
|
|
|
|
|
thanks for all the info. I've been using DataReaders so far and just came across the adapter. So I'll stick with the reader.
|
|
|
|
|
Hello,
I try to find how to set the property " User must change password at next log on " and i don't found.
somebody knows how to change this property ?
ThankYOU !!
|
|
|
|
|
See the "Where Password Attributes Reside" section at this[^] page.
/ravi
|
|
|
|
|
I forgot to say , i develop by using c# .
NOT VBS.
|
|
|
|
|
How about this[^] article?
/ravi
|
|
|
|
|
So what? The concepts don't change just because the programming language did.
Or were you looking for copy'n'paste code?
|
|
|
|
|
The function and how to set the the property is difrent ..
|
|
|
|
|
No, it's not. The exact same concepts and procedures still apply. The only difference is you use the classes in the System.DirectoryServices namespace to do the searching and manipulation. If you understand the concepts behind that VBS code, it's very easy to figure out how to write the equivilent code by reading the documentation on System.DirectoryServices classes and looking at the examples there.
Research is the number one skill you MUST have in order to survive writing code for a living...
|
|
|
|