|
I've got to the point where i'm handling unalocation of COM objects, but i'm curious, i've seen examples using both IMalloc wrapped objects and Marshal.Release / ReleaseComObject to handle disposal.
Which one is best protocal? Is IMalloc really nesscesary?
I get the impression that the Marshaler is actualy an IMAlloc wrapper, in which case, i don't actualy need to build and worry about an IMalloc object for things like Freeing and assigning memory to pointers.
Cata
|
|
|
|
|
"unalocation"....that seems wrong to me grammatically, somehow
Anyways, I've always taken the approach of using the "ReleaseComObject" method, and I've never noticed any substantial memory leakage. I'm fairly certain you shouldn't need the IMalloc style unless you're using a custom marshalling approach.
I may be right, may be wrong, who knows
Jeremy Kimball
|
|
|
|
|
Jeremy Kimball wrote:
"unalocation"....that seems wrong to me grammatically, somehow
That theres won of them werds we amerIcans like to yous. yall know what im talkin bout. <lived in the south for 5 years>
---------------------------
He who knows that enough is enough will always have enough.
-Lao Tsu
|
|
|
|
|
Heh...spent a good deal of my childhood a bit south of Macon Georgia
|
|
|
|
|
Wow ok I lived in Kennesaw Georgia for 2 years. Down town was a place called "Wild Man Dent Myers" where you could go in and buy a KKK outfit plus all the stars and bars your heart could desire. Outside the shop was a sign, "Olypukes go home" (as the 1998 Summer Olypics were being held in Atlanta).
Scary stuff. Never did get to see Wild Man Dent Myer in person though. Maybe that's a good thing heheh.
---------------------------
He who knows that enough is enough will always have enough.
-Lao Tsu
|
|
|
|
|
My bad. Unallocation.... perhaps not the best word to use.
Anyhoo... glad that i'm on the right (gramaticaly retarded) track!
I'm from england, and i'm also a writer... so i am feeling somewhat foolish. I blame the alcohol!
Cata
|
|
|
|
|
Deallocate is the the correct term methinks. However, dictionary.com doesn't know what deallocate is . Well, in the unmanaged realm of programming, we'd always use "deallocate". MSDN has several articles on "deallocating memory" from unmanaged code, too.
---------------------------
He who knows that enough is enough will always have enough.
-Lao Tsu
|
|
|
|
|
Before I get going here, allow me to apologise for this thread not making much sense.
ok now thats out of the way, let me try and explain whats going on here.
I have a normal C# form that contains a data grid (DevExpress XtraGrid, although I dont think that is relevant). The configuration for the grid is held in an XML file, so when the form loads it reads the XML data and via a configuration class it configures the grid with all the require parameters etc etc.
The problem that I have is that I need to handle grid events and these events must reside within the form class and not the configuration class.
To overcome this problem I have created a delegate, in the form I create a list of the required delegates and send them to the configuration class when it is called.
so this is what we have so far :
public class ControlVars
{
public delegate void gridEvents ( object sender, EventArgs e );
}
public class Initialisation
{
public data[] InitGrid(XmlDocument configXdoc, Hashtable EventDelegates)
{
...snip (case data comes from the XML file)
case "xmldata_combobox":
myComboBox.SelectedIndexChanged += ???????????????????????
break;
case "xmldata_text":
myText.TextChanged += ???????????????????????
break;
...snip
}
}
public class MyForm
{
private ComboBox_GridEvent1....
private Text_GridEvent2....
...
private void myForm_Load(object sender, System.EventArgs e)
{
Hashtable EventDelegates = new Hashtable();
EventDelegates.Add("comboboxselected_event", new ControlVars.gridEvents(ComboBox_GridEvent1));
EventDelegates.Add("textchanged_event", new ControlVars.gridEvents(text_GridEvent2));
...snip
Initalisation init = new Initialisation();
GridData[] gData = init.initGrid(configXdoc, EventDelegates);
myGrid.DataSource = gData;
}
}
Where I am stuck is what to do when I need to set the event handler for the item I am generating, I have the Hashtable that contains the delegates and I have tried to set the event handler to use:
myControl.MyEvent += new EventHandler(eventDelegates["event_description"]);
And variations thereof but I am not getting anywhere.
Hopefully that will make sense to somebody who can put me on the right track.
post.mode = postmodes.signature;
SELECT everything FROM everywhere WHERE something = something_else;
> 1 Row Returned
> 42
|
|
|
|
|
Don't have time at this second to really dig deep into the real issue, but out of curiosity, have you tried casting the value in the Hastable to your delegate type?
i.e,
myControl.MyEvent += new EventHandler(eventDelegates["event_description"]);
becomes
myControl.MyEvent += new EventHandler((ControlVars.gridEvents)eventDelegates["event_description"]);
|
|
|
|
|
I think this was most certainly a case of not seeing the wood for the trees - your suggestion works and is also blindingly obvious
Thanks alot
post.mode = postmodes.signature;
SELECT everything FROM everywhere WHERE something = something_else;
> 1 Row Returned
> 42
|
|
|
|
|
No problem
|
|
|
|
|
A few questions...
I take it that new ControlVars.gridEvents(ComboBox_GridEvent1) (or similar) would return a new delegate that points to the method?
Also, what exactly isn't working? If I'm assuming the statement above correctly, this seems like it should work. When you start attaching handlers (delegates) to the events, so long as you specify the key that corresponds to the event, this should hook-up the handler to the event that is defined in your Form class. The .NET FCL assemblies actually use a similar approach in many places (explicitly defining a hashtable or collection for event handlers as opposed to letting the compiler do it automatically).
So, to set the handler in the first block of code, you'd have something like:
myComboBox.SelectedIndexChanged +=
EventDelegates["ComboBox.SelectedIndexChanged"] Here I'm making things a little easier and assuming that you change the hash key to something easier to associate (like {TypeName.EventName}).
If you wanted to handle hook up handlers at runtime using discovery, you could do something like this (note: not optimized - only an example):
Type t = myControl.GetType();
EventInfo[] events = t.GetEvents(BindingFlags.Instance | BindingFlags.Public);
foreach (EventInfo event in events)
{
string name = string.Format("{0}.{1}", t.Name, event.Name)'
if (EventDelegates.ContainsKey(name))
event.AddEventHandler(myControl, EventDelegates[name]);
}
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Dear all,
I was wondering if any of you guys know of a way of hot swapping a logged in account's policy? Basically, I know of a way to move an account from one OU to another while it is logged in. After that's done I want that new OU to be applied without having to log the user out and back on again.
Any ideas?
Regards,
Kev
|
|
|
|
|
And this has to do with C# how?
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Sorry, I'm coding an app in C# to do all of this. Using DirectoryEntry, etc.
|
|
|
|
|
Okay, but this has more to do with Active Directory than C#. Looking at the Microsoft KB, there was nothing mentioned I found. From experience, though, you typically have to log out and log back in for changes like this to take effect. I know that you can re-apply a group policy while the user is logged in (and AD clients can poll group policies at set intervals), but I don't know how you would change the OU for a user while they're logged in.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Hi guys
Let me know if managed c++ has any advantage over c#
Why should somebody choose managed c++ instead of c# while both of them use .net framework as their base classes?
|
|
|
|
|
Managed C++ gives you untethered access to unmanaged code (C# can do pointers and the like, but only in an unsafe context). Managed C++ is really ugly right now though, especially with all the underscore-underscore keywords. The next version (Whidbey) of Managed C++ promises to improve the syntax of it greatly.
I guess the reason one would choose managed C++ over C# is for shear power and performance. MC++ already gives you more power than you currently have in C#, and Whidbey promises to improve on that. For example, say you created a class that inherits from ArrayList and overrides the OnAdd methods. While C# would have to adhere to the overridden methods, MC++ could actually access the underlying ArrayList and call the base methods, something not possible in C#.
For performance, Whidbey MC++ will supposedly output a .NET IL more highly optimized than any other .NET language. Of course, MC++ can always drop down into unmanaged land or even x86 assembly if you need to write extremely performance critical code.
Finally, if you need to interoperate with the C runtime library, write pure COM objects, or utilize templates, MC++ is a nice option to have.
So there you go, if you like to have fine control over everything and you need to write performance-critical code, MC++ is a nice option at your disposal. Be warned though, there are a few documented bugs using mixed managed/unmanaged code in MC++. That, plus the syntax for MC++ is proposed to change with Whidbey.
---------------------------
He who knows that enough is enough will always have enough.
-Lao Tsu
|
|
|
|
|
Judah H. wrote:
While C# would have to adhere to the overridden methods, MC++ could actually access the underlying ArrayList and call the base methods, something not possible in C#.
Um, use the base keyword in C#:
public override int Add(object o)
{
base.Add(o);
} It's been available since C# 1.0.
And this stuff about performance isn't necessarily true. IL (MSIL to be exact) is still the output of the source language. While loops and the like can be optimized, the instructions to call methods, get and set properties, and similar procedures cannot. The "power and performance" argument is moot unless you call a lot of native code so that marshalling isn't really an issue in nested native calls.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Heheh yeah I know that Heath. I think you misunderstood, what I meant is that MC++ consumer code can call base methods. Any C# code can call the base method from within the inherited class, but C# consumer code of that class cannot, while MC++ consumer code can in fact do this. Take the following example
class SomeClass : ArrayList
{
public override int Add(object value)
{
if ( ((int)value) == 0 )
throw new ApplicationException("no 0's allowed!");
return base.Add (value);
}
}
ArrayList list = new SomeClass();
list.Add(0);
ArrayList* list = new SomeClass();
list::ArrayList->Add(0);
Hope that clarifies.
---------------------------
He who knows that enough is enough will always have enough.
-Lao Tsu
|
|
|
|
|
Why choose one over the other? The biggest reason is to use whatever you feel most comfortable using.
Both C++ and C# can use unsafe code (i.e., manipulation of pointers) but C++ can use unverifiable code (mixed mode compilation that calls native APIs directly), which is nice in some circumstances (like when you want to use a LOT of native APIs and not have to redefine them and their supporting structs and consts in .NET structs and consts) but create problems for code hosted in remote environments (when, without changing the code groups for code access security, unverifiable code can't run).
It really doesn't matter either way, though. Pure Managed C++ and C# compile down to IL which gets JIT'd and executed at runtime when needed. These assemblies can be used by any other language that targets the CLR so the choice is yours.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
For me, some of advantages are:
1. IJW - an easy way to interoperate with unmanaged code.
2. Possibility to directly reuse existing C++ libraries.
3. RAII[^] and __nogc types in general.
4. No explicit boxing. While it looked like an iconveiniance in beginning, I quickly learned that it actually protects us from subtle, hard to fing bugs.
However, there are some dissadvantages as well:
1. It is hard to produce verifyable code with MC++.
2. Bugs[^]
|
|
|
|
|
Only place I've ever seen a positive need for MC++ is when it comes to vast chunks of native code (that isn't easily converted), or when writing Custom Marshallers. Oh, and before the Managed libraries came out for DirectX, that as well.
Jeremy Kimball
|
|
|
|
|
I need to use functionality from another dll, but I don't know the dll name and/or entry point at compile time. It will be available at runtime. I'm sure the compiler is doing something to the dllimport attribute to make it happen, so I was wondering if it's possible to do it at runtime.
Also, the dll is taking as one of it's attributes class that was written in c++ and is part of that dll. Is it possible to somehow instantiate this class in C#, populate it's fields and pass it to dll?
Thanks.
|
|
|
|
|
No, the compiler does link it, the runtime does. All the compiler does is attribute the declaration with the information you provide in the DllImportAttribute for an extern'd method. The runtime (CLR) uses the DllImportAttribute metadata to link against the native API at runtime.
If you're looking for something like LoadLibrary and GetProcAddress , then P/Invoke those methods and use them accordingly. You should be able to declare a delegate that the GetProcAddress P/Invoked method would return, but I've never tried this. Seems like with some fanagling you should be able to get this to work. Otherwise, create a native DLL that you would ship with your assembly (in a resolvable path, of course) that takes a string and some params or something then does all the loading and resolving itself.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|