|
In our upcoming CMS (zeta producer 8 [^]), I am doing this for both <a href = "http://msdn2.microsoft.com/en-us/library/system.windows.forms.treeview.aspx" rel="nofollow">TreeView</a> [<a href = "http://msdn2.microsoft.com/en-us/library/system.windows.forms.treeview.aspx" target = "_blank" rel="nofollow">^</a>] and <a href = "http://msdn2.microsoft.com/en-us/library/system.windows.forms.listview.aspx" rel="nofollow">ListView</a> [<a href = "http://msdn2.microsoft.com/en-us/library/system.windows.forms.listview.aspx" target = "_blank" rel="nofollow">^</a>] as you described.
I do handle the SelectedIndexChanged event of the ListView and TreeView and change the ContextMenuStrip property to either of 3 predefined ContextMenuStrip controls.
In Addition I enable/disable menu items in those ContextMenuStrips based on the content of the selection (i.e. whether a single or multiple items are shown).
This works exactly the same for both TreeView and ListView.
|
|
|
|
|
i've a cross thread problem
i searched the net alot and i still can't solve it
here is a complete sample of the code
WaitCallback callback ;string username;
fn(object sender,eventargs e )
{
callback = delegate(object state) { this.ExcuteFN(); };
}
void ExcuteFN()
{
//MethodInvoker.Combine(callback);
try{
this.usertableadapter.insert(textbox2.text,combox1.selectedvalue);}catch(){}
finally{textbox1.clear();}
}
the problem that another thread is accessing the control that created by main thread
ofcourse i don't want the dirty solution to stop the control check
i tried the
MethodInvoker.Combine(callback);but no way, i tried many other solution but also no way
any solution plz provide full details
|
|
|
|
|
I use the (from memory) WorkerThread class all the time now. It has callbacks to the main thread which I can use to do any UI updates that need to happen during and after the thread.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
You mean BackgroundWorker?
|
|
|
|
|
No i'm working with (WaitCallback )delegate
its equivlant to backgroud worker but more better
|
|
|
|
|
WaitCallback is a delegate. BackgroundWorker is a component that helps you update UI controls on the right thread while still doing background work on another thread. See this article[^].
|
|
|
|
|
ummm, what i know is the invokerequired property but this is for windows forms controls, and i see use tabledataadapter.
to use invokerequired:
delegate void MyDelegate(object Data);
void some method()
{
.........
if(Control.InvokeRequired)
{
YourControl.BeginInvoke(new MyDelegate(this.controlupdatemethod),new object[] {yourdata});
}
}
void controlupdatemethod(object data)
{
//Do Whateve you want here in your control
}
|
|
|
|
|
Ok your in another thread you created...<br />
<br />
<br />
public class HeavyJobThread<br />
{<br />
public delegate void NotifyUI();<br />
public event NotifyUI OnNotifyUI;<br />
<br />
<br />
protected void ThreadProc()<br />
{<br />
<br />
if (OnNotifyUI!= null)<br />
OnNotifyUI.BeginInvoke(null, null);<br />
}<br />
<br />
<br />
<br />
<br />
void HeavyJobThread_OnNotifyUI()<br />
{<br />
NotifyUI();<br />
<br />
}<br />
<br />
<br />
private void NotifyUI()<br />
{<br />
if (this.InvokeRequired)<br />
{<br />
NotifyUICallback cb = new NotifyUICallback(NotifyUI);<br />
this.Invoke(cb, null);<br />
}<br />
else<br />
{<br />
textbox1.Clear();<br />
}<br />
}
.net is a box of never ending treasures, every day I get find another gem.
|
|
|
|
|
Hello Gentlemen.
I'm having a bit of trouble figuring out why a right click control I programmed is not functioning correctly.
Here is my initbutton function for the most part.
public void InitButtons()<br />
{<br />
int counterx = 0;<br />
int countery = 0;<br />
string buttonname = "button";<br />
<br />
for (int i = 1; i <= 81; i++)<br />
{<br />
this.BLISTS.Add(i, new ButtonList());<br />
this.BLISTS[i].ReInitList();<br />
this.button.Add(i, new System.Windows.Forms.Button());<br />
this.button[i].Location = new System.Drawing.Point(173 + (countery * 65), 61 + (counterx * 66));<br />
this.button[i].Size = new System.Drawing.Size(63, 60);<br />
this.button[i].Name = i.ToString();<br />
this.button[i].TabIndex = i;<br />
this.button[i].Text = this.BLISTS[i].ShowNum();<br />
this.button[i].UseVisualStyleBackColor = true;<br />
this.button[i].Enabled = true;<br />
this.button[i].Visible = true;<br />
this.button[i].AccessibleRole = System.Windows.Forms.AccessibleRole.Default;<br />
this.button[i].BackgroundImageLayout = System.Windows.Forms.ImageLayout.Tile;<br />
this.button[i].BackColor = System.Drawing.Color.Ivory;<br />
this.button[i].Cursor = System.Windows.Forms.Cursors.Default;<br />
this.button[i].MouseClick += new MouseEventHandler(this.MouseLRClick);<br />
countery++;<br />
if (i % 9 == 0)<br />
{<br />
counterx = counterx + 1;<br />
countery = 0;<br />
}<br />
Controls.Add(button[i]);<br />
}<br />
}<br />
And here is the event handler:
private void MouseLRClick(object sender, MouseEventArgs e)
{
Button temp = sender as Button;
if (temp != null)
{
if (e.Button == MouseButtons.Right)
{
temp.BackColor = Color.Red;
return;
}
/* if (e.Button == MouseButtons.Left)
{
temp.BackColor = Color.LightGray;
return;
}*/
}
}
For whatever, reason, the button never turns red, never depresses, and the focus never switches. Is there some aspect of the MouseButton.Right I am not understanding here?
Thanks for your time.
|
|
|
|
|
Have you set a breakpoint to see if the event fires ?
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Not yet. That is a good idea.
|
|
|
|
|
No, it doesn't seem to be fireing. The Event is not even being picked up. I can spam the right mouse button all day, and it doesn't even move into the MouseLRCLick function.
|
|
|
|
|
Override OnMouseDown and detect MouseButtons.Right from MouseEventArgs e:
protected override void OnMouseDown( MouseEventArgs e )
{
base.OnMouseDown( e );
if ( e.Button == MouseButtons.Right )
if ( null != f_RightClick )
f_RightClick( this );
}
|
|
|
|
|
Or (at least) call your MouseLRClick method from OnMouseDown. "Right-click" requires this handling because there is no formal right click event. I haven't tried it lately, but I believe there is some kind of anomalous behavior if you try to detect right "click" (mouse down) in a Click delegate (which may be your experience -- that Click would not fire in response to a right MouseDown/Click).
In other words, you needed to use an event that would be fired by the right mouse button being pressed and/or released within the usual timeframe of a "click" event. I believe, because a right click is not detected by Click, that the OnMouseDown event is your only viable candidate. Generally, your purposes will be able to drop time frame considerations. Otherwise (to qualify a true "click" time frame), you will have to measure the timespan between MouseDown and MouseUp. For almost any usual purpose, this probably is redundant.
|
|
|
|
|
Timing doesn't enter into it. You can hold a Button down with the left mouse button as long as you want and it won't Click until MouseUp. Also you can press the left mouse button and then move the mouse away from the Button and the Button return to unpressed with no Click or MouseUp being triggered.
What I do is:
on MouseDown I store a reference to the control that triggered it
on MouseEnter or MouseLeave I clear the value (just in case)
on MouseUp I compare the control that triggered MouseUp with the control that triggered the MouseDown, and if they're the same I raise an event and clear the value
|
|
|
|
|
I think timespan is only a factor if you are distinguishing double-clicks.
I like what you are doing, though.
|
|
|
|
|
I seem to recall (from an hour ago) that MouseEventArgs contains info to help detect double-clicks.
|
|
|
|
|
Clicks returns the number of times that the control was clicked, but I'd have to do some work to determine if it returns the number of right clicks (unless we counted them) or whether the right-clicks were executed within the system parameters for recognizing a "double click."
|
|
|
|
|
I'm still chewing on this (and not about to throw it away). Just wondering... I can see how you might be doing this in an application, but are you writing controls based on this principle (which may require logical involvement *all* controls)?
|
|
|
|
|
No, I don't write my own controls.
I have a private MouseTrap field in my Form. Then any controls (like Buttons) for which I want to simulate right-clicks I use:
MouseTrap.Add ( button1 ) ;
Which adds the MouseTrap's methods as handlers for the Controls' MouseUp, MouseDown, MouseEnter, and MouseLeave events.
If a Control triggers a MouseDown followed by a MouseUp (with no MouseLeave or MouseEnter in between) then the MouseTrap raises its own MouseClick event.
I write a general MouseClick handler to figure out which Control fired the event, but I may be able to streamline that.
Anyway, this is just something I have been dreaming up for a few weeks and finally waded into today. It may be a while before I have something that's ready for prime time.
|
|
|
|
|
I'm pleased with my right mouse behavior, but I think your idea is quite cool for many purposes.
A suggestion crosses my mind. Manual registration of controls may be the way to go for some users, but you can also provide the option of automating the registration process -- performing the following process for instance based on the value of a boolean field:
After creating your form, run a process which iterates its Controls array and the Controls arrays of each control it encounters. In this cycle, register your delegate(s) to each control's Up/Down/Enter events as necessary, filtering for whatever classes of controls you intend to support. That should automatically wire your process -- and make your form the first automatic mouse trap!
|
|
|
|
|
I think you want the MouseUp event.
I just spent some time this afternoon working on making buttons and things "right clickable" too.
|
|
|
|
|
I probably won't revise all my old RightClick code, but I have to admit your suggestion is an intriguing approach -- more correct in regard to allowing (possibly) the operator to mouse out of the control before mouse up. But it's not what I'd want to do in terms of timely response. To get fancy, I would measure the time-span from right mouse-down. Otherwise, MouseUp is an interesting alternative we should probably consider for the given purposes.
|
|
|
|
|
That's why I wrote a class (MouseTrap) and added it to my derivation of Form. Now all my Forms will have this ability built in.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
