|
In this case, source code is the only thing that will help us solve your problem. This includes the code surrounding your chatMessageForm.Show() method.
If my answer has helped you, one of my articles may also be a help. Also remember that your best friend's name is google.
|
|
|
|
|
Well the code looks a bit like this.....
public partial class ChatMessageForm : Form<br />
{<br />
public ChatMessageForm()<br />
{<br />
InitializeComponent();<br />
}<br />
}
private void ProcessChatMessageEvent()<br />
{<br />
ChatMessageForm c = new ChatMessageForm();<br />
c.Show();<br />
<br />
}<br />
ProcessChatMessageEvent is called by.....
public void OnEvent(Object sender, EventPublisher.EventPublisherEventArgs eventArgs)<br />
{<br />
EventID nReceivedEvent = (EventID)eventArgs.iEventID;<br />
switch (nReceivedEvent)<br />
{<br />
case EventID.eChatMessageEvent:<br />
ProcessChatMessageEvent();<br />
break;<br />
}<br />
}
I checked and it works properly outside of the switch which kinda amazes me.
(The OnEvent is a Cisco event handler)
|
|
|
|
|
aei_totten wrote: works properly outside of the switch
Hmm, so your saying that the following code would work:
public void OnEvent(Object sender, EventPublisher.EventPublisherEventArgs eventArgs)
{
ProcessChatMessageEvent();
}
If my answer has helped you, one of my articles may also be a help. Also remember that your best friend's name is google.
|
|
|
|
|
Richard Blythe wrote: Hmm, so your saying that the following code would work:
yes
|
|
|
|
|
well crud. I can't even reproduce that today 
|
|
|
|
|
The difference between Show and ShowDialog is that the first method displays the form and continues with the next line of code, while the second method pauses execution of the code until after the form has been closed. Observe:
MyForm F = new MyForm();
F.ShowDialog();
System.Diagnostics.Debug.WriteLine("Output");
In this case, the string Output will not be written to the Immediate window until the pop-up form is closed. If you replace F.ShowDialog() with F.Show(), Output will probably be written before the form finishes rendering.
I suspect that your calling code needs to wait until the dialog has been handled, which is why ShowDialog works and Show does not. This can be a real pain if you are writing a MDI application, as child windows cannot be invoked with ShowDialog.
Added: After looking at the code you posted above, I can see the problem. After calling Show(), the method ends. The variable referencing your form goes out of scope and gets recycled: your form is not getting a chance to render before it gets disposed. If it absolutely has to be modeless, you will need to move the scope of your form's variable out.
|
|
|
|
|
Gregory.Gadow wrote: Added: After looking at the code you posted above, I can see the problem. After calling Show(), the method ends. The variable referencing your form goes out of scope and gets recycled: your form is not getting a chance to render before it gets disposed. If it absolutely has to be modeless, you will need to move the scope of your form's variable out.
Now, that makes sense.
However, in the real application, I have more demands of that form (I just wanted to get a simple one working first because I was running into this issue and couldn't pin point it).
Here's some code....
private Dictionary<string, ChatMessageForm> chatMessages = new Dictionary<string, ChatMessageForm>();<br />
...<br />
string message, sender; <br />
message = "blah";<br />
sender = "me";<br />
if (!chatMessages.ContainsKey(sender))<br />
{<br />
chatMessages.Add(sender, new ChatMessageForm(sender));<br />
}<br />
chatMessages[sender].ShowDialog();}
The Dictionary is declared outside of the process in the scope of the main form. However, i do think the issue is related. This is my first time using Dictionary so maybe I am missing something there...
|
|
|
|
|
Found out something else.
Even without the Dictionary, just moving the declaration of the Form out into the scope of the main form was not enough to fix the problem
|
|
|
|
|
Based on your last post, it seems that you need to look into the Cisco event behavior. For example, a standard windows event will not give you this behavior. Try trapping an event from your main form like this:
public frmMain()
{
InitializeComponent();
frmMain.Click += new EventHandler(frmMain_Click);
}
ChatForm frmChat;
void frmMain_Click(object sender, EventArgs e)
{
if (frmChat == null)
{
frmChat = new ChatForm();
frmChat.Show();
}
frmChat.BringToFront();
}
If this works without a hitch (which it should), then you should contact Cisco and report a bug! 
If my answer has helped you, one of my articles may also be a help. Also remember that your best friend's name is google.
|
|
|
|
|
Thanks for the relpy. It does work fine from a button event or other main form generated event.
However, I created a System.Timers.Timer and called the method from it's elapsed event handler and that created the same freeze as seen from the Cisco event handler.
|
|
|
|
|
Okay, maybe it's a thread issue. Most of my apps doesn't required thread sensitive code. Try using thread context code like this:
...
{
InvokeMethod();
}
private delegate void EmptyHandler();
private void InvokeMethod()
{
if (this.InvokeRequired)
this.Invoke(new EmptyHandler(InvokeMethod), null);
else
{
ChatForm frmChat = new ChatForm();
frmChat.Show();
}
}
This create the new chat for on the same thread as the main form.
Maybe a long shot, but it may be what your looking for...
Cheers,
Richard
If my answer has helped you, one of my articles may also be a help. Also remember that your best friend's name is google.
|
|
|
|
|
That did it.
I had tried previously checking if the dialog needed invoke but i didn't check this.invokerequired
Thanks so much!
|
|
|
|
|
Great! I was a pro and didn't even know it. 
Maybe you'll have the answer for me when I need it.
If my answer has helped you, one of my articles may also be a help. Also remember that your best friend's name is google.
|
|
|
|
|
I was wondering if it was possible to eject USB and CD roms drives of a remote computer? I have seen code out there for local machines, but nothing really remote.
I have tried this one for a remote that I found:
const int OPEN_EXISTING = 3;
const uint GENERIC_READ = 0x80000000;
const uint GENERIC_WRITE = 0x40000000;
const uint IOCTL_STORAGE_EJECT_MEDIA = 2967560;
[DllImport("kernel32")]
private static extern IntPtr CreateFile
(string filename, uint desiredAccess,
uint shareMode, IntPtr securityAttributes,
int creationDisposition, int flagsAndAttributes,
IntPtr templateFile);
[DllImport("kernel32")]
private static extern int DeviceIoControl
(IntPtr deviceHandle, uint ioControlCode,
IntPtr inBuffer, int inBufferSize,
IntPtr outBuffer, int outBufferSize,
ref int bytesReturned, IntPtr overlapped);
[DllImport("kernel32")]
private static extern int CloseHandle(IntPtr handle);
public static void EjectMedia(string computer, char driveLetter)
{
string path = "\\\\" + computer + "\\" + driveLetter + ":";
IntPtr handle = CreateFile(path, GENERIC_READ | GENERIC_WRITE, 0,
IntPtr.Zero, OPEN_EXISTING, 0,
IntPtr.Zero);
if ((long)handle == -1)
{
throw new IOException("Unable to open drive " + driveLetter);
}
int dummy = 0;
DeviceIoControl(handle, IOCTL_STORAGE_EJECT_MEDIA, IntPtr.Zero, 0,
IntPtr.Zero, 0, ref dummy, IntPtr.Zero);
CloseHandle(handle);
}
But have had no luck with it...
|
|
|
|
|
Jacob Dixon wrote: I was wondering if it was possible to eject USB and CD roms drives of a remote computer?
Nope. You cannot do it unless the code that's triggering the eject was running on the remote machine.
Jacob Dixon wrote: I have seen code out there for local machines, but nothing really remote.
There's a reason for that...
DeviceIoControl only works on the machine the call was made on.
|
|
|
|
|
Great! Thanks for the reply. I'll create a service to install on the local machines to perform that action and some others
|
|
|
|
|
Dave Kreskowiak wrote: There's a reason for that...
Moving parts of a remote machine may be hazardous.
|
|
|
|
|
Oh, come on! What's wrong with closing the coffee cup tray without warning?
|
|
|
|
|
Why some people move the using into the namespace. Can reduce the size of the program file?
For example,
namespace test
{
using System;
using System.Net;
public class classA
{
...
}
}
modified on Wednesday, July 7, 2010 11:28 AM
|
|
|
|
|
It is just the matter of coding guidelines on follows. IMO using statements should be outside the namespace.
yu-jian wrote: Can reduce the size of the program file?
IMO it cannot alter the file size. (I thought you meant keeping using statements inside namespace would reduce file size)
The overall file size would reduce since you will not be using fully qualified names everywhere in the code. It also makes the code more readable.
modified on Monday, April 19, 2010 1:03 PM
|
|
|
|
|
That doesn't depend on where the directive is.
d@nish wrote: It also makes the code more readable.
Not once it's pasted in a forum.
|
|
|
|
|
I am only fully of curiosity that why coder does that. So I guess whether it can reduce the file size. Now I know it not reduce the exe size, but it is a good way to make code more readable.
Thanks for your reply. 
|
|
|
|
|
Hi,
such using statements do not contribute to the EXE/DLL file size.
All they do is allow for a smaller source file, as they enable shortcuts such as TextBox for System.Windows.Forms.TextBox
|
|
|
|
|
 And I thought he is saying that keeping using statements inside namespace would reduce file size.
|
|
|
|
|
It will have no effect on the compiled size. The difference in source code size depends on how you indent the code within the namespace.
I'm not a fan of the using directive at all, but if you are using it to define aliases, it allows things like:
namespace MySqlClientStuff
{
using Connection = System.Data.SqlClient.SqlConnection ;
...
}
namespace MyOleDbStuff
{
using Connection = System.Data.OleDb.OleDbConnection ;
...
}
However, those may be better in separate files anyway.
There should be little need for multiple namespaces within one file, so the point is fairly meaningless.
More recently I have started putting the using directives for namespaces that contain my Extension Methods inside the namespace, but that's just me.
P.S. In a further contrarian vein...
Were someone to concatenate a bunch of C# code files into one big file, using directives outside the namespaces would cause trouble.
modified on Monday, April 19, 2010 1:23 PM
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
