|
This thread should have an answer: Click here
--
David Wengier
Sonork ID: 100.14177 - Ch00k
|
|
|
|
|
I'm sorry, I didn't remember I already asked this question in this place. I'll try it out...
|
|
|
|
|
Well, I tried:
override protected void WndProc(ref Message m)
{
int message = m.Msg;
if ( message == 0x0012 ) //WM_QUIT
{
}
else
if ( message == 0x0010 ) //WM_CLOSE
{
// Who closed the form?
}
base.WndProc(ref m);
}
but is seems that quitting windows does not raise the WM_QUIT event. It raises the WM_CLOSE event, though. But how can I check who closed the form? I don't know how to use LParam of WParam?
|
|
|
|
|
I am truly at a loss... It appears that every single event that is raised to ask if the program/form should close just asks not providing any information as to why its asking.
I've even fiddled with using reflection to get at some internal members, but all I get is "member not found" errors 
Here's what I've found if you want to investigate it further
Inside of the Application class is a nested type called ThreadContext.
You can get the Type for this with this bit of code.
public Type GetThreadContextType() {
MemberInfo[] typesInApp = typeof(Application).FindMembers(
MemberTypes.NestedType,
BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.Public,
new MemberFilter(memFilter), null
);
return MemberInfo[0].DeclaringType;
}
private bool memFilter(MemberInfo m, object filterCriteria)
{
if( m.Name.IndexOf("ThreadContext") != -1 )
return true;
else
return false;
}Now that class has a static method called "FromCurrent" which takes no arguments and returns the ThreadContext for the current application. This is retrieved by looking up a LocalDataStore on the Thread, the LocalDataStoreSlot is stored in a static field named tlsSlot, this slot corresponds to the thread's ThreadContext object.
Once you have an instance of ThreadContext you can call the GetState method passing in the value 0x10 to see if the Thread has an AppQuit message posted or pass in 0x08 to see if the Thread has a Quit message posted.
Here is the code I've been pounding out since you posted your message, if anyone can get it to work I'll buy you a beer the next time you are in the area 
Type app = typeof(Application);
MemberInfo[] typesInApp = app.FindMembers(
MemberTypes.NestedType,
BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.Public,
new MemberFilter(memFilter), null
);
Type typeThreadContext = typesInApp[0].DeclaringType;
object threadContext = Thread.GetData(
(LocalDataStoreSlot) typeThreadContext.InvokeMember(
"tlsSlot",
BindingFlags.NonPublic | BindingFlags.GetField | BindingFlags.Static,
null, null, new object [] { }
)
);
bool StatePostedAppQuit = (bool) typeThreadContext.InvokeMember(
"threadState",
BindingFlags.GetField | BindingFlags.NonPublic,
null, threadContext, new object[] { 0x10 }
);
bool StatePostedQuit = (bool) typeThreadContext.InvokeMember(
"threadState",
BindingFlags.GetField | BindingFlags.NonPublic,
null, threadContext, new object[] { 0x08 }
);You'll need the memFilter method from the first chunk of code above.
Feel free to completely destroy that bit of code, I'm getting an exception on the line that retrieves the threadContext. I've tried by using the FromCurrent method and the method above (which basically does what FromCurrent() does).
Now I get to go take my car in to get a flat tire fixed 
James
Sonork: Hasaki
"I left there in the morning
with their God tucked underneath my arm
their half-assed smiles and the book of rules.
So I asked this God a question
and by way of firm reply,
He said - I'm not the kind you have to wind up on Sundays."
"Wind Up" from Aqualung, Jethro Tull 1971
|
|
|
|
|
Found another (rather simple solution  ), like this:
protected override void WndProc(ref Message m)
{
const int WM_SYSCOMMAND = 0x0112;
const int SC_CLOSE = 0xF060;
if (m.Msg == WM_SYSCOMMAND && (int) m.WParam == SC_CLOSE)
{
// User clicked close button
OpenDialog(false);
return;
}
base.WndProc(ref m);
}
Kind regards,
Ludwig
|
|
|
|
|
Doh!
I like your version much better 
James
Sonork: Hasaki
"I left there in the morning
with their God tucked underneath my arm
their half-assed smiles and the book of rules.
So I asked this God a question
and by way of firm reply,
He said - I'm not the kind you have to wind up on Sundays."
"Wind Up" from Aqualung, Jethro Tull 1971
|
|
|
|
|
Well, thanks anyway for the answer! Meanwhile I've joined this forum, because it's one of the best I've seen.
Ludwig
|
|
|
|
|
Gday All,
I have a performance /design question regarding whether it
is better to implement helper functions for a class as
static members or as global/namespace functions.
For example:
namespace MyObjCtrl {
class MyObject {
public:
//static member that uses a MyObject ( option 'A' )
static HelperStyleA( MyObject* pObj );
};
//namespace helper function of option 'B'
HelperStyleB( MyObject* pObj );
};
//implementation of option 'B'
MyObjCtrl::HelperStyleB( MyObject* pObj )
{
}
If anyone could give me a run down on the pros and cons of
these two methods or of any website or tutorial that might
help, it would be much appreciated
|
|
|
|
|
This is actually a C++ question, but I'll answer it.
There is not performance issue here just a stylistic one. I personally prefer static functions over global functions as they imply a link to a given context.
Cheers,
Tom Archer
Author, Inside C#
|
|
|
|
|
I created a collection class using the .NET help files, but when I add objects to the collection, it appears as though the each new object copies itself throughout the collection--all objects in the collection become equal to the new added object. Anyone run into this before?
Here's a snip of code to give you a idea of what I'm doing...
namespace NatesKentuckyRook.Classes
{
public class RookCards : System.Collections.CollectionBase
{
// Constructors
public RookCards()
{
}
// Functions
public void Reset()
{
List.Clear();
}
public void AddCard(RookCard Card)
{
List.Add(Card);
}
}
}
|
|
|
|
|
Take a look at CollGen2 on GotDotNet. It will create a collection for you using the type you specify.
As to your problem I've not seen it before.
James
Sonork: Hasaki
"I left there in the morning
with their God tucked underneath my arm
their half-assed smiles and the book of rules.
So I asked this God a question
and by way of firm reply,
He said - I'm not the kind you have to wind up on Sundays."
"Wind Up" from Aqualung, Jethro Tull 1971
|
|
|
|
|
There's nothing in the code you posted that would cause the problem you're describing. Can you post a sample app - especially the client code?
Cheers,
Tom Archer
Author, Inside C#
|
|
|
|
|
I want to know how can I send command via socket to another computer on my LAN like take a screenshot, send a message, Controls the computer, something with the same concept as Netbus but for my LAN monitoring ?
Thanks
P.S Source code will be very appreciated
|
|
|
|
|
I just wanna transfer a piece of code from cpp code to csharp.
To my surprisse, csharp doesn't have the union key word.
Then how can cope with the union in cpp to keep the code change minimized.
any suggestion?
|
|
|
|
|
C# is a type safe language, and a union is every thing that a typesafe language is not.
Therefore you will have to create a conversion operator or function to cast from type A to type B.
|
|
|
|
|
If you need to interop with a C/C++ object that uses a union you can do that, but there isn't a way to create a union in C# that behaves the same way (well easily create a union, you can re-create the VT_VARIANT type by using an enum and a lot of casting).
James
Sonork: Hasaki
"I left there in the morning
with their God tucked underneath my arm
their half-assed smiles and the book of rules.
So I asked this God a question
and by way of firm reply,
He said - I'm not the kind you have to wind up on Sundays."
"Wind Up" from Aqualung, Jethro Tull 1971
|
|
|
|
|
Well, I try to use set and get to simulate the union. It seems work in my eye.
class A
{
public int a;
}
class B
{
public char b;
}
class union
{
object obj;
public A aa
{
get
{
return (A)obj;
}
set
{
obj=value;
}
}
public B bb
{
get
{
return (B)obj;
}
set
{
obj=value;
}
}
}
|
|
|
|
|
Can a component obtain a reference to its container object?
I'm writing a component that needs two pieces of information about its container:
1. Is the container a form?
2. If so, what is its window handle? (.Handle property)
The "Container" object only lets me access a very limited interface that doesn't do what I want.
--Thanatos
|
|
|
|
|
You should be able to test the Container object for what type it is, then once you know it is a specific type you can cast it to that type and access the property you want.
ie
if( Container is System.Windows.Form ) {<br />
System.Windows.Form containerForm = (Form) Container;<br />
}
HTH,
James
Sonork: Hasaki
"I left there in the morning
with their God tucked underneath my arm
their half-assed smiles and the book of rules.
So I asked this God a question
and by way of firm reply,
He said - I'm not the kind you have to wind up on Sundays."
"Wind Up" from Aqualung, Jethro Tull 1971
|
|
|
|
|
That sounded good, so I tried this test:
I built a simple component with this method:
public void ChangeParentColor()
{
if( Container is Form )
{
Form containerForm = (Form)Container;
containerForm.BackColor = Color.Aqua;
}
}
This built just fine. I placed this component on a new form, along with a button. When the button was clicked, this method fired:
private void buttonclick(object sender, System.EventArgs e)
{
containerTestComponent1.ChangeParentColor();
button1.Text="I was clicked";
}
This project also built just fine, but even though the caption of the button changes properly (demonstrating that the button event fired), the color of the form refused to change to aqua.
|
|
|
|
|
While i'm not going to offer any advice in the container issue... I just thought you might like to know that that code is not the best way to do what you are doing.
It's better* to do this:
Form containerForm = Container as Form;
if( containerForm != null ) {
// Use containerForm
}
*
"better" meaning that the produced IL is smaller and faster.
If you don't believe me, make a simple executable and examine the IL yourself.
The general rule-o-thumb is:
If you are going to do a cast directly after an "if-is" and use that casted object, use "as" instead.
If you just want to test the type and not do something with the object as that type, use "is".
|
|
|
|
|
Hmm...
I haven't done any tests to see if (Container is Form) evaluates to true; I just assumed it would if the container was a form. If it doesn't, that could be the reason why the code isn't running.
Your method may work where the other did not. I'll try it out when I get home.
|
|
|
|
|
Nope, it doesn't work. Upon further inspection, ( containerForm != null ) is evaluating as false, indicating that something is wrong with the typecasting.
I'm thinking it may not be possible to cast a Container to a Form...
...in which case I'll have to do things the hard way: pass the form to the component as a parameter. I'd rather not, though, if I don't have to.
|
|
|
|
|
why don't you do a:
Type containerType = Container.GetType();
and see what the container really is?
|
|
|
|
|
In addition to what Andy wrote your best bet is to code for the lowest common denominator. If you only need to use properties/methods that a control has, then compare to System.Windows.Forms.Control.
The container may not be a form but it could be a Panel, or a UserControl or some other class.
James
Sonork: Hasaki
"I left there in the morning
with their God tucked underneath my arm
their half-assed smiles and the book of rules.
So I asked this God a question
and by way of firm reply,
He said - I'm not the kind you have to wind up on Sundays."
"Wind Up" from Aqualung, Jethro Tull 1971
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
