|
I'm looking for something like the old Windows API FlushEvents().
I have a form which creates a COM object like such:
COMServerObject foo = new COMServerObject;
While my code waits for this singular statement to return, Windows makes my form window modal. If it takes a while for this statement to return - up to 20 seconds for .NET to give up and throw an exception - Windows queues up mouse clicks and keyboard events on my form, and then plays them back once the statement returns.
This is nasty, as the user hammers away at my unresponsive window, even trying to close it. So once the statement returns, my window can suddenly fly around the screen, resize, minimize, and even close.
I've tried disabling the Form while while I wait:
...<br />
this.Enabled = false;<br />
COMServerObject foo = new COMServerObject;<br />
this.Enabled = true;<br />
...
And this prevents clicks on my various buttons and menus. However, it does NOT prevent clicks on the window frame or title bar or close controls, so they still get queued up.
How can I prevent these from queuing? In the old Windows API, you could call FlushEvents when you got back from a modal state, which would remove all Windows events from it's message queue. I can't find anything analogous in the .Net framework. Anybody know the proper technique, here?
|
|
|
|
|
JoeRip wrote: Anybody know the proper technique, here?
Yeah, some asynchronous coding methods.
Put the call to your COM object in background thread so the primary thread is free to handle the events.
only two letters away from being an asset
|
|
|
|
|
So, nobody knows any way to flush events, then?
|
|
|
|
|
With a decent design, nobody ever needs to flush events. An app is not supposed
to ignore its user, if it can't or won't respond to some event, it should
disable the event sources to indicate so. 
|
|
|
|
|
Luc Pattyn wrote: With a decent design, nobody ever needs to flush events.
This is an overly simplistic statement. Both the Mac OS and Win32 API's support a Flush Events procedure, which is recommended to prevent users from inadvertently losing work or destroying data.
In the professional productivity applications that I was personally involved in shipping, we frequently flushed queued up events when a dialog opened, to prevent a user who was typing in word processor from overwriting original values in the dialog controls without intending to do so.
While you may not agree that the situation I described needs an event flush, your statement that it is never necessary is incorrect.
|
|
|
|
|
Well, if you want your app to suddenly open a dialog, give it focus, and hijack all
on-going user input, then you are on your own I guess. I will try and avoid ever
using such an app, the way I see it the user is in control, not the app.
|
|
|
|
|
How bizarre that you would suggest that I want this. Where are you reading that I want an application to suddenly open a dialog?
Can you not simply admit that your statement was overly simplistic and incorrect?
|
|
|
|
|
Hrmmm I should chuck my 2c in here.
Sometimes (probably due to a less than ideal architecture) you may find a whole bunch of events in your queue. The correct behaviour here is to process the events. You may choose to fast-discard keypresses and clicks - but the decision to flush the queue may cause your application to lose critical information. You could lose network connectivity change notifications, system shutdown notifications...
Particularily if you are intending to have your application run on Vista - which is very very quick to detect applications not pumping their message queue, and very quick to suggest they are hanging and should be closed.
So I don't think it was "overly simplistic and incorrect". It was good advice, on par with "do not call GC.Collect()". Sure - you could think up a scenario where it might be useful - but in 99% of cases you should just do it right.
If you need to flush your message queue then use PInvoke to call the API function. If the framework supports this it will be in the Application or Form class. It probably doesnt, because its bad practice. HTH
|
|
|
|
|
All arguments aside, here's an odd behavior: Application.DoEvents() basically does the flush for me.
If I do this:
myForm.Enabled = false;
COMServerObject foo = new COMServerObject();
Application.DoEvents();
myForm.Enabled = true;
Then the queued clicks on the titlebar/closebox/minimize box, etc, do NOT get received by my app. If I reverse the order of the last two statement (enable the form, then call DoEvents()), then the messages DO get received by my app. Weird.
Noted just for interest. Not advocating this as a method to flush events.
|
|
|
|
|
Hi friends,
I have below salesreport table, how can I get results of max sales of sales persons in one query?
salesperson sales orderId
Michele 120 120121
Guido 230 120122
Michele 300 120123
Michele 250 120124
Franco 100 120125
Guido 500 120126
Franco 400 120127
the query result must be;
salesperson sales
Michele 300
Guido 500
Franco 400
|
|
|
|
|
This is more for the SQL forum methinks.
Also sounds very much like homework.
Anyway here is the solution (try and understand why it works rather than just copying it)
<br />
select salesperson,max(sales)<br />
from salesreport<br />
group by salesperson<br />
Regards
Guy
You always pass failure on the way to success.
modified on Friday, December 28, 2007 4:27:52 PM
|
|
|
|
|
Thanks so much.
You are right. It is a homework but only a part of my homework. I made it simple to apply my question. I am getting query from northwind databasesample. According to sales person's most sold products, I am using group by also and other things. I can't where anad how to put max to below code. The below code gives, all sales of salespersons according to product.
select employees.Firstname,employees.lastname,products.productname,
sum("order details".unitprice*quantity*(1-discount)) as Sales from ((Employees inner join orders on employees.employeeID=orders.employeeID) inner join "order details" on orders.orderID="order details".orderID) inner join products on products.productID="order details".productID
group by employees.lastname,employees.firstname,products.productname
order by employees.firstname
As you see, I don't have any aim to copy your response. I have gotten stuck in a point and I wanted help.
|
|
|
|
|
omegazafer wrote: You are right. It is a homework but only a part of my homework.
I appreciate your honesty in this.
With regards to the query - it's not the simplest of queries you have written - a suggestion: break it into it's component parts and get those parts working first.
omegazafer wrote: ((Employees inner join orders on employees.employeeID=orders.employeeID) inner join "order details" on orders.orderID="order details".orderID) inner join products on products.productID="order details".productID
looks overly complex to me(does it work?).
Regards
Guy
You always pass failure on the way to success.
|
|
|
|
|
Thans so much, your first response helped me so much because I didn't know the using of max with group by.
You can be sure, that code is working also it is the response of one question of my homework.
Now, i am dealing the other question I asked you.
Regards
Good Days
|
|
|
|
|
I want to access folders which are not in Inbox but outside my inbox, like my personal folders using c#.
I am using Outlook Object Library 11.0.
Would appreciate someones help.
|
|
|
|
|
|
Thanks for your help,
I had already visited that and tried below
Outlook._Application olApp = new Outlook.ApplicationClass();
Outlook._NameSpace olNS = olApp.GetNamespace("MAPI");Outlook._Folders oFolders;
oFolders = olNS.Folders;
Outlook.MAPIFolder oPublicFolder = oFolders.Item("Public Folders");
oFolders = oPublicFolder.Folders;
Outlook.MAPIFolder oAllPFolder = oFolders.Item("All Public Folders");
oFolders = oAllPFolder.Folders;
Outlook.MAPIFolder oMyFolder = oFolders.Item("My Public Folder");
Console.Write(oMyFolder.Name);
But it is not working giving an error at oFolders.Item("Public Folders");
|
|
|
|
|
Cut and paste from the page linked above.
"
Folders object -
You can use the Folders object to refer to any folder that is in the Outlook folder list. The Folders object is typically used to refer to a Microsoft Exchange folder or to any other folder that is not a default Outlook folder.
The following sample code illustrates how to refer to a public folder that is named My Public Folder. Notice that you typically start at the top-most folder and then work your way down to the folder that you have to reference. Also notice that the folder names are case-sensitive. You must exactly match the capitalization and the names as they appear in the Outlook folders list.
"
I'd double check this.
Just because we can; does not mean we should.
|
|
|
|
|
I read that but I got error before that and am yet to reach there.
Outlook._Application olApp = new Outlook.ApplicationClass();
Outlook._NameSpace olNS = olApp.GetNamespace("MAPI");Outlook._Folders oFolders;
oFolders = olNS.Folders;
Outlook.MAPIFolder oPublicFolder = oFolders.Item();
oFolders.Item is not defined thats what it says me.
|
|
|
|
|
Lets assume I have a folder named "SPAM".
I'd write that line like:
Outlook.MAPIFolder oPublicFolder = oFolders.Item("SPAM");
Maybe I'm not understanding you correctly....If thats the case, I'll leave it to someone else.
Just because we can; does not mean we should.
|
|
|
|
|
You are almost there!
What i mean is when we write
Outlook.MAPIFolder oPublicFolder = oFolders.Item("SPAM");
when i write oFolders and press ".", i don't see "Item", means oFolders doesn't have a definition of "Item" and it throws me error there itself. Specifing the folder name "SPAM" will be checked in the next step.
Hope you are getting me now.
Appreciate and Thanks a million to you!
|
|
|
|
|
OK, I get you now.
Try this out and see what you get for folder names or just refer to the folder by index.
<br />
Microsoft.Office.Interop.Outlook._Application olApp = new Microsoft.Office.Interop.Outlook.ApplicationClass();<br />
Microsoft.Office.Interop.Outlook._NameSpace olNS = olApp.GetNamespace("MAPI"); <br />
Microsoft.Office.Interop.Outlook._Folders oFolders;<br />
oFolders = olNS.Folders;<br />
<br />
for (int i = 0; i < oFolders.Count; i++)<br />
{<br />
Microsoft.Office.Interop.Outlook.MAPIFolder oPublicFolder = oFolders[i].;<br />
Console.Write(oPublicFolder.Name);<br />
}<br />
Just because we can; does not mean we should.
|
|
|
|
|
Thanks for that, but it gave me out of index error, but i just twisted your code somewhat and this is what i did and got the folder details i need.
Outlook.Application OApp = new Outlook.ApplicationClass();
Outlook.NameSpace ns = OApp.GetNamespace("MAPI");
Outlook.MAPIFolder inbxfld = ns.GetDefaultFolder(Outlook.OlDefaultFolders.olFolderInbox);
Outlook.MAPIFolder prsnlfldr = ns.GetDefaultFolder(Outlook.OlDefaultFolders.olFolderInbox);
Outlook.Folders pfldr = ns.Folders;
Console.WriteLine(pfldr.Count);
foreach(Outlook.MAPIFolder fld in pfldr)
{
Console.WriteLine(fld.Name);
}
Thanks a million for your help and getting me out of this
Now I am going a step further!
Btw, liked your line "Just because we can; does not mean we should."
|
|
|
|
|
I am trying to create a method where if a user clicks on the checkbox of a treeview node it deletes it only if it is a childnode but does not delete it if it is a rootfolder. This is how I started. If anybody can give me a clue and show me how to make it work? Thanks.
private bool CheckBox(TreeNode tn)
{
if (tvFavorites.SelectedNode.Checked == true)
{
//tn.Nodes.Remove();
tvFavorites.SelectedNode.Remove();
}
else
{
return CheckBox(false); and here I get an error that "Best overloaded method: invalid argument.
}
}
modified on Friday, December 28, 2007 2:36:51 PM
|
|
|
|
|
A) To solve your problem, check to see if the selected node is a child node and perform your actions accordingly.
B) Your error; You are calling the function CheckBox passing the variable of type bool when its expecting type TreeNode. To solve, simple replace that line with "return false;"
Just because we can; does not mean we should.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
Be Humble in Victory and Strong in Defeat.