|
Hi
You just need to call the event handler 
Like:
First derive from Button, then add the following:
public void CallButtonClick()
{
base.OnClick(this, EventArgs.Empty);
}
Now , call the function from your code
Hope this helps, there seems to be many ways to do this though.
Give them a chance! Do it for the kittens, dear God, the kittens!
|
|
|
|
|
Hi Leppie,
I am not sure if I understand what you mean by 
leppie wrote:
First derive from Button, then add the following:
public void CallButtonclick()
{
base.onclick(this, EventArgs.Empty);
}
Can you please give more detailed explaination? I really appreciate that!!;)
|
|
|
|
|
D Shen wrote:
I am not sure if I understand what you mean by
It's the beauty of inheritance 
OK. Lets see how/why I say that
1. What we want is a button that we can programatically fire events. It makes sense to add this functionality to the Button class. So we make one:
public class ButtonEx():System.Windows.Forms.Button
{
public void CallButtonclick()
{
base.OnClick(EventArgs.Empty);
}
}
2. We replace our existing Button in the in the form with our new ButtonEx.
private System.Windows.Forms.Button button1;
private ButtonEx button1;
And in the windows forms designer region, change :
button1 = new System.Windows.Forms.Button();
button1 = new ButtonEx();
Be sure to save before viewing in the designer(in fact close it beforehand, it does more harm than good  ).
3. Finally we just call our new ButtonEx's CallButtonClick methods as follows:
button1.CallButtonClick();
NOTE: If you'll be calling this method from thread u will need to invoke it. I'm not 100% sure, but it would look something like this:
button1.Invoke( new MethodInvoker(button1.CallButtonClick));
Hope this adds some insight
Give them a chance! Do it for the kittens, dear God, the kittens!
|
|
|
|
|
Thank you, leppie. It really helps!
|
|
|
|
|
leppie,
Here comes a minor problem 
When I compile the code, I got "...does not contain a definition for..." this button1.
I followed the order you post here, but.... Please help!!
|
|
|
|
|
leppie,
I found the problem, it was so stupid.....(typo )
|
|
|
|
|
Hehe, thought it was either that or the designer screw'd up the UI 
Give them a chance! Do it for the kittens, dear God, the kittens!
As seen on MS File Transfer: Please enter an integer between 1 and 2.
|
|
|
|
|
Sorry, I'm a bit DOPEY 
I didnt see that it was a combobox you were talking about, but the way to do it is the same, just follow the steps 
Give them a chance! Do it for the kittens, dear God, the kittens!
|
|
|
|
|
Does anybody know if there is a way to use the GetFiles method to retrive files using more than one search pattern (similar to what you can do with the OpenFileDialog class). For example, I want to use the GetFiles method to return all image files with the *.jpg, *.bmp, *.gif, etc extensions but it seem the method will only take one at a time and won't accept a string in the same format as the the FileDialog class. I thought about making multiple calls to GetFiles and putting the results into a stack and then popping them out one-by-one to sort them together into one array but I wanted to see if anybody could come up with an easier way.
Thanks
|
|
|
|
|
There isn't a very easy way but you could get all the files, regardless of extension and then remove all the ones that don't fit the profile (a quick RegEx will do that neatly).
Paul
|
|
|
|
|
I have this code in my Clear() routine:
ds.Tables[0].Rows.Clear();
grdProducts.Refresh();
ds is an in-memory DataSet, not associated with any database, a simple way to access what's in the DataGrid. grdProducts if of course a DataGrid.
The problem is that most of the times I run this code there's an unhandled NullReferenceException exception ("Object reference not set to an instance of an object").
Looking at the stack trace, it happens when the DataGrid is painting itself (after a WndPaint event). If I omit the grdProducts.Refresh() call in my code, I don't see any of my functions in the stack trace, but adding it makes the function in progress appear several levels down the trace (obvious).
Any ideas??
-- LuisR
──────────────
Luis Alonso Ramos
Chihuahua, Mexico
www.luisalonsoramos.com
"Do not worry about your difficulties in mathematics, I assure you that mine are greater." -- Albert Einstein
|
|
|
|
|
Hi
I cant seem to see the problem...
But I have a suggestion is that as you are trying the clear the rows, clearing the table would have the same effect, so will clearing the Columns. Perhaps a cross reference is causing the null reference exception.
Hope this helps
Give them a chance! Do it for the kittens, dear God, the kittens!
|
|
|
|
|
leppie wrote:
But I have a suggestion is that as you are trying the clear the rows
I'm trying to clear the records that the user added. Any other way to do it??
One time, and only one time, I saw another exception about a negative row number.
-- LuisR
──────────────
Luis Alonso Ramos
Chihuahua, Mexico
www.luisalonsoramos.com
"Do not worry about your difficulties in mathematics, I assure you that mine are greater." -- Albert Einstein
|
|
|
|
|
Hmm, DataTable.Rows.RemoveAt() ??? Very strange indeed!
Give them a chance! Do it for the kittens, dear God, the kittens!
|
|
|
|
|
I added a if(dt.Tables[0].Rows.Count > 0) before clearing all rows, and it seems to work now...
-- LuisR
──────────────
Luis Alonso Ramos
Chihuahua, Mexico
www.luisalonsoramos.com
"Do not worry about your difficulties in mathematics, I assure you that mine are greater." -- Albert Einstein
|
|
|
|
|
I am calling a DLL function from my C# application, but when the application is executed, it takes approximately 5 seconds to complete it.
But if I throw a breakpoint before the call, and step thru it, the function runs in only 1 second?!? 
I am letting it run 10 times with and without break points, and it stays consistent.
This is sooo backwards from what I was expecting. Any ideas on why breaking to debug mode speeds up the process!?
See the 3rd message down for a better description of what is happening
|
|
|
|
|
psdavis wrote:
I am calling a DLL function from my C# application, but when the application is executed, it takes approximately 5 seconds to complete it.
Its normal for any .NET language to have a delay at application start.
psdavis wrote:
But if I throw a breakpoint before the call, and step thru it, the function runs in only 1 second?!?
Weird? Can you please supply me some more details, what function are you calling and the implementation?
psdavis wrote:
I am letting it run 10 times with and without break points, and it stays consistent.
More details, you dont state how you loop it? I hope you are not just restarting the application everytime, if so refer to above
psdavis wrote:
This is sooo backwards from what I was expecting. Any ideas on why breaking to debug mode speeds up the process!?
My only debug problems is , that when stopping at a breakpoint and trying to step thru the lines (in rare cases i might add), that the application just freezes. 
Give them a chance! Do it for the kittens, dear God, the kittens!
|
|
|
|
|
leppie wrote
Its normal for any .NET language to have a delay at application start.
/nod, but this is in response to a menu item being selected.
leppie wrote
Weird? Can you please supply me some more details, what function are you calling and the implementation?
Unfortunately, it is an outside library that opens up a file in a specific format. I've used this library for a good 5 years though, and it's always run in under a second.
But basically, I'm doing a 'select file', 'open file' when a menu option is selected.
leppie wrote
More details, you dont state how you loop it? I hope you are not just restarting the application everytime, if so refer to above
Nah, just clicking 'File-Open' again with different file names each time. I've run the test around 20 times now, with mix and matches of the files and it's extremely consistent.
|
|
|
|
|
Little more info...
It's OpenFileDialog causing the slowdown!!!?
private void menuItem7_Click_1(object sender, System.EventArgs e)
{
OpenFileDialog pFileOpen = new OpenFileDialog( );
pFileOpen.InitialDirectory = @"J:\Aware\SPECS\EFTS\6.2\Samples\10_subs";
pFileOpen.Filter = "EFTS Files (*.eft)|*.eft|All files (*.*)|*.*";
pFileOpen.FilterIndex = 1;
if( pFileOpen.ShowDialog( ) != DialogResult.OK )
return;
EFTS.EftsFile pEftsFile = EftsVerification.LoadEftsFile( pFileOpen.FileName );
Classification.Classify pDialog = new Classification.Classify( );
pDialog.EftsFile = pEftsFile;
pDialog.ShowDialog( this );
}
If I comment out the OpenFileDialog part of the code and give the LoadEftsFile the name of the file directly, then it loads normal and quick.
Seems that OpenFileDialog is doing some sort of 4 second clean up?!?
|
|
|
|
|
For this test, I created a new dialog that allowed you to type the name of the file.
I then replaced OpenFileDialog with TestFileDialog and left the rest of the code exactly the same.
OpenFileDialog - 4 seconds
TestFileDialog - 1 second
There is something seriously wrong with that function.
|
|
|
|
|
Hmm, drive J:, a network drive. If so, Windows is taking its time looking for all the pretty icons for the files in the FileDialogBox seriously! Try to set to list or details view...
I never had problems with that though...
Give them a chance! Do it for the kittens, dear God, the kittens!
|
|
|
|
|
Thanks Leppie, but the 3 second differential is after it closes, not while it's loading the icons. Also tried it on the local drive.
Now get this!! OpenFileDialog seems to be keeping the file that you selected busy for 3 seconds or so after you click 'ok'!!
EFTS.EftsFile pEftsFile = EftsVerification.LoadEftsFile( @"J:\Aware\Specs\EFTS\6.2\samples\10_subs\car2.eft" );
Here I manually override the Load to load a specific file. If I select a different file car3, then we're back to one second. If I select the 'same' file car2, then it's back to 4 seconds again.
|
|
|
|
|
if( pFileOpen.ShowDialog( ) != DialogResult.OK )
return;
Stream myStream = pFileOpen.OpenFile( );
if( myStream != null )
myStream.Close( );
EFTS.EftsFile pEftsFile = EftsVerification.LoadEftsFile( pFileOpen.FileName );
GRRrrrr!!! I tried this on a hunch. Once I select my file, then I open it up and immediately close it. The time is EXACTLY the same, but just in different order. The OpenFile/Close takes about 2-1/2 seconds and my LoadEftsFile is back to normal again.
Is OpenFileDialog trying to open up my file?!
|
|
|
|
|
psdavis wrote:
If I select a different file car3, then we're back to one second. If I select the 'same' file car2, then it's back to 4 seconds again.
So its file related? How does the size differ?
CheckFileExists Overridden. Gets or sets a value indicating whether the dialog box displays a warning if the user specifies a file name that does not exist.
CheckPathExists (inherited from FileDialog) Gets or sets a value indicating whether the dialog box displays a warning if the user specifies a path that does not exist.
Try disabling both these... This about as much as I can help Brain is starved now.
Give them a chance! Do it for the kittens, dear God, the kittens!
|
|
|
|
|
> So its file related? How does the size differ?
Copy of the original file.
> CheckFileExists & CheckPathExists
Way ahead of you bro. No change.
I guess I'm going to have to recreate the OpenFileDialog until they fix the bug. Unfortunately, they don't even have any problems reported with OpenFileDialog reported on their knowledgebase, nor do I have a couple of hundred bucks burning a hole in my pocket to report it.
Anyone know of a OpenFileDialog replacement control?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
