Adding events like Oncopy,Oncut,Onpate to a dynamically generated text box - c#

Hai Guys,
How to add events like oncopy,onpaste to a dynamically generated textbox in a windows form applications...

I'd first consider sub-classing TextBox.
If there are "many" of these TextBoxes you will create; I'd think about whether they can and will be possibly removed at run-time, as well as added : whether there are some circumstances in which you would ever want to "dis-connect" one or all of the special events from being processed by one or all of these special TextBoxes.
While you could adopt a strategy of overriding the ProcessCmdKeys for the Form (with Form preview key enabled) to handle globally the issue of relevant keystate at the Form level, I wouldn't go there; I would want to isolate it to the special case textbox. The discussion of ProcessCmdKeys here :
link text
May be useful to you.
I'd want to create special class to handle instantiation and management of these special textboxes, and their "endownment" with these special event-raisers : you might want to keep a List<TextBox> of the ones currently being used to "track" them. Or, if you are sub-classing, List<SpecialTextBox>.
... note we're skipping over the whole issue of the possibility of a paste or copy being triggered by a selection from the TextBox default menu : are you enabling that ? Is that important to you ? Do you need to "suppress that menu" ? If you wish to still have that menu, and still "catch" the events : imho you are going to have to sub-class TextBox and define a WndProc and catch events like WM_Paste there. ...
There's a pretty complete example of code for sub-classing a TextBox and handling ProcessCmdKeys and trapping the kinds of events you are interested in here :
link text
But please note I haven't used or tested the above code myself, it was just filed away in my "archive" of snippets, but, at the very least, it will give you a basis for study ... if you have to sub-class.

Related

Which Button called this form?

I have 2 problems:
"Which Button called this form?" (short version)
I can not touch the button or button's form
Why do I want this?
I have many forms and need to know how the user got there. If I could get the Form (not the button) it may also solve the problem.
Long version: I need to copy some properties of source form/button to the new one without do it manually and I intend to use it later on Exception reporting to catch more info
Initially, i tried to do a "newForm.Caller = this;" on each button but there are 200+ forms and lots of buttons on each.
All forms and it's buttons are custom controls so I can do things there.
Tried things
I tried to do things with StackFrames and reflection at form constructor but don't work (889310)
I found this 10401190 for JAVA but it can't help
I thought I could use the OnClick override to store the last button instance in a static place in buttons/forms class then get it in the form constructor but seems to be the worst solution. (Many things open forms and the culprit would be the last button pressed)
The problem get worse when other things open Forms and I lost the reference (DataGridVewButton, timers, linked label, ...)
EDIT1: (oɔɯǝɹ)
Another detail, forms can be called from external Plugins. So again I don't have acesses to the code to change it.
EDIT2: Example (Graham Bass,ShreyasKapur)
FormA has a ButtonA that when clicked shows FormB
FormA inherits FormBase
Button inherits ButtonBase
FormB inherits FormBase
I can NOT change FormA neither ButtonA codes, only FormBase and ButtonBase codes
Edit3: (Bradley Uffner)
ShowDialog() forms have the Owner property that solves part of the problem. Thanks Bradley, I forgot about that!
Unfortunately, all existing code uses the parameterless constructor.
"Displays this form as a modal dialog box with no owner window" (1)
I would think that you are trying to solve the wrong problem.
When your forms are this interconnected, you coupled them to tightly. By coupling them even more tightly by looking back to who called you, you are only making you problem worse. See also: the comefrom instruction.
I would suggest passing parameters between your forms to supply them the data they need. But keep the number of parameters to an absolute minimum, and don't try to use something like caller, that would be cheating.

Real Time Output Of Processed Inputs

Being a beginner in C# I am having problem in a specific implementation. I need to compute two data in real time by which I mean ki the output shows as soon as the inputs are provided with no click of button necessary.
- For example I have a Text Box where if a type a number 5 gets added to it and the output shows in a Label. The label automatically updates when more numbers are typed in real time.
How do I achieve this?
Thanks !
Before explaining the specifics, it's important to point out that from the code's perspective there isn't much difference between clicking a button or responding to the TextBox's event. Here's what I mean.
In addition to calling code procedurally from within your own methods like this:
void MyMethod(argument)
{
...Other Code...
DoSomething(argument);
...Other Code...
}
.Net also allows you to attach method calls to Events. Events are just references to delegates(I'll leave it up to you to research delegates), but they allow you to asynchronously execute your code based on external interaction.
In your question you say that you want to perform a calculation without making the user click a button. Before going into how you'll accomplish that, lets think about what you'd do if there were a button. Chances are you'll drag & drop a button onto the designer surface, then double click it. Behind the scenes you'll suddenly have a method that looks something like this:
void button_ButonClick(object sender, ClickEventArgs args)
{
DoSomething();
}
So you'll go and populate the new method's body with your calculation logic. Under the hood you've actually just had the designer hook that new method up to the Button's click event. So in your case, whether you're adding the calculation logic to a button click or the TextBox's TextChanged event, you're actually doing almost the same thing.
Just for reference, here's the MSDN documentation for TextBox's TextChanged event .
OK I will give it a shot :)
Assume two textboxes and a label on a form.
Each textbox has a text_changed event handler, i.e. if you type something in either text box, the event handler code is called and there you can access the text of each textbox and transform the text into two numbers.
Then you compute the 2 numbers as per your rules and the result is displayed in the label.
This is a very simplified explanation! There must be validation of the inputs in the textboxes to ensure the data format is correct.
Ask more questions if this is not clear enough.

How can I create dynamic controls in response to a button click?

I want to fill an updatepanel with new dynamic controls in response to a button click.
However, I also want to be able to access the values of these dynamic controls in response to an event in one of the controls.
Specifically, I want the button to bring up two dropdownmenus. One of the menus (or both if need be) is in another update panel. I want the first menu in the update panel to change its data in response to a value getting selected in the other menu.
I think my problem is that when I cause a postback with one dropdownmenu I lose the other dropdownmenu because I created it in the button_click handler.
I know I should create dynamic controls in the Page_Init method (or so ive heard) but I only want the controls to show up if the button is clicked. There are other buttons on the page which need to create a different set of dynamic controls.
Thanks.
There are a lot of ways you can handle this, and which approach to take really depends on your project's requirements and your available resources.
The smoothest way to do it that would generally provide the best user experience would be to use a Javascript technique to hide and show controls as the page required them. JQuery is the library I would recommend for this. On the most basic level, you simply wire the control's activation (such as a button_click event) and hide or show a div containing the dynamic content as necessary, like so:
$("#control").show();
// and
$("#control").hide();
Alternatively, you can do this in C# by using the Visible property on many of the normal web controls for ASP.NET. The usual code-behind approach would look something like this:
private void btnControl_Click(object sender, EventArgs e)
{
var dynamicControl1 = FindControl("dynamicControl1");
dynamicControl.Visible = false; // or true, as the case may be
}
This particular approach is mostly attached to code-behinds, though, which I would encourage you to avoid if possible. They are practically impossible to test and will make projects a pain to work in. You can use a similar approach in the MVC3 framework, of course, it will just be a little different how you send and receive the control you are setting to not be visible. The other benefit this has that is kind of nice is that if something is set to not be visible, it tends not to even be displayed in the HTML generated by the templating engine (YMMV depending on the engine, but I know this is true in Razor). So someone viewing the source of your webpage won't be able to see inactive controls, which may or may not be something that appeals to you.
EDIT: I see the problem is less to do with how to display these things, and more with how to create and read them back given on-the-fly input.
I'm sure there's a way to do this with Javascript (which would more than probably be the cleanest and best way to do this), but I'm not good enough with JS to know the answer to that one. The way you would handle this in ASP.NET is make the div you're going to add controls to server-side (by using runat='server', then add what you need there. Again, the trivial code-behind approach would be something like:
private void btnControl_Click(object sender, EventArgs e)
{
foreach(var checkBoxChecked in chkBoxes.Where(x => x.Checked))
{
div.Controls.Add(new WebControl()) // or whatever the heck else it is you need.
}
}
This presumes that you have an IEnumerable<CheckBox> to iterate over, of course. You may also want an IList<WebControl> to keep track of all the junk you're adding. You will also need to make sure the CSS is applied properly to the div for the controls you're adding. And again, code-behinds are pretty awful and I use the example only because it'd be easy to spin up in a project to test for yourself.

What to do when a form's class becomes too large?

Currently my main form has a ton of event handlers because there are a lot of controls. It is very similar to a paint application. I have condensed it down quite a bit and I am sharing event handlers whenever possible but the class is still around 1,000 lines of code. I realize that may not be much to all of you but it is considerably larger than the rest of my classes.
I have refactored a lot of code to other classes but all those event handlers still increase the line count by a large amount. I also started using region blocks to separate event handlers in to groups and that is working rather well but I still would like to know SO's opinion on the matter as to best organize a large amount of form event handlers.
Edit: So I've been using partial classes and I must say, I don't really like them that much. I'm not sure what to do at this point.
I may go back to using region blocks as I'm not sure user controls will help my problem at all. Honestly I did not mind the region blocks that much. That class was the only place I used them and it organized the different sections of the code quite nicely (Menu Event Handlers, Toolstrip Event Handlers, Drag and Drop Support, et cetera).
Still, if anyone still has any other ideas or would like to elaborate upon any posted thus far I'd be more than appreciative as I am still looking for a better solution to this problem.
1000 lines of code is nothing, and that should not be the basis for refactoring your code. Refactor your code where it makes sense; not just because a class contains more lines of code than your other classes. Some classes will require more code than others, and that's perfectly okay.
That being said, if it makes sense you can divide the controls into logical sections, and put them in user controls. Make sure that there is a good justification for doing so though, because otherwise you'll only be convoluding your code base.
I must remind you again though, don't split your code up just to reduce the lines of code.
You could either split the functionality into separate classes (e.g. creating UserControls like Ed has suggested), or think about using partial classes (where one class can be split among many files). I have found partial classes handy to group together related chunks of code, when the "main" class file is getting to large. Sometimes this is the first step in refactoring those chunks of code into separate classes and/or controls.
It's hard to make a concrete recommendation without seeing the code, but those are some of your options.
If you haven't already (you don't mention it) I would split out the various individual controls into UserControls. You can handle all of the events from within the UserControl class and only expose those events that the parent form must absolutely handle. These will likely be small in number and will drastically reduce the responsibilities of your main form.
For example, each tool button could live inside of a UserControl. The canvas control can maintain and instance of the tools control and so on. You can keep creating the composite controls where each upper layer becomes less complicated and most of the actual logic is handled below it.
I would suggest of using more OOP solution. Do not add UserControls, as you add more *complexity*. Let's try to maintain complexity you already have, but make things more clear, cause this is what really you're asking for, I believe.
DI like. In practise if you need to handle a lot of events for a lot of contorls, create ControlManagers, which accepts in ctor the control and subscribes to its events.
So for every control you will have it's own manager.
Advantages:
Clear separated code in different classe, so easy recognizable in case of problems and my be more clear from architectural point of view.
You don't break down your architecture with a lot ot delegated events between tons of controls and subcribers (one subscriber per control)
Sure you will need organise, by the way, the data flow between different classes. But it's by my experience, haven't to be a big problem.
EDIT
An example pseudocode:
UserControl1 mycontrol1; UserControl2 mycontrol2;
public class MyControl1Manager {
public MyControl1ManagerFor1 (UserControl1 uc1) {
//subscribe to events of uc
// here all code to handle events
}
public MyControl1ManagerFor2 (UserControl2 uc2) {
//subscribe to events of uc
// here all code to handle events
}
}
and somewhere in code:
MyControl1ManagerFor1 controlManager1 = new MyControl1ManagerFor1 (mycontrol1);
MyControl1ManagerFor2 controlManager2 = new MyControl1ManagerFor2 (mycontrol2);
Something like this.
Hope this helps.
Once I had a form that became really big. It showed the same information in many various ways. To reduce number of code in single file I used an approach similar to UserControls. All the GUI elements were placed on the form, but their initialization and handlers were maintained by helper classes. They were equivalents of UserControls, but without GUI interface. These classes were initialized in main form's constructor:
SideViewHelper sideView = new SideViewHelper(parentForm, gridControlMaster, gridControlDetail, buttonSubmit);
All the logic that handles the gridControl events, button events are handled inside the helper class.
After the initialization the main form (parentForm) may change state of many UI items by single call of ViewHelper's method.
These classes are created for this only form and are as lightweight as possible.

How can I create a Delphi TSpeedButton or SpeedButton in C# 2.0?

How can I create a Delphi TSpeedButton or SpeedButton in C# 2.0?
Using a Button and setting the TabStop property to false only works when tapping through the form...
If you need (as I did) a button that does not get selected when clicking on it, there is only one way I have found to do it.
The way I did it, was to subclass the Button class and in the constructor calling the SetStyles and thereby setting Selectable to false, like so:
public class ButtonNoFocus : Button
{
public ButtonNoFocus()
: base()
{
base.SetStyle(ControlStyles.Selectable, false);
}
}
This worked out for me, and is perfect if you e.g. have a control-panel with buttons that perform actions to a selected object...
I'm wondering if you want to create a control like a TSpeedButton, or you just need same kind of end result ...
Programming one from scratch is certainly possible, but I'd only tackle that as a learning exercise.
Assuming you want to achieve a similar end result ...
Delphi's TSpeedButton had a differences from the standard TButton that developers found useful - it was flat, didn't take focus, and it consumed fewer resources than a regular button (because it didn't have an underlying Windows Handle).
Which of these are important to you?
If you just want a flat button that doesn't accept focus, use a regular Button with FlatStyle=Flat (or PopUp) and TabStop=false. You can configure a glyph by setting either the Image property, or a combination of ImageList and ImageIndex/ImageKey.
An alternative to this would be to look for an existing button component that comes close to your needs - one place to look might be the Krypton Toolkit (free to use, see http://www.componentfactory.com/toolkit_buttoncontrols.php).
If you're wanting to reduce the number of resources consumed by your application, it's likely you'll get a better return looking elsewhere.
Back in the days of Windows 3.1 (Delphi 1) and Windows 95 (Delphi 2), the number of available handles was strictly limited, with a maximum number available system wide. Today, with Windows XP and Vista, the number of available handles is far far higher, and the number is per process, not system wide. Unless you're creating thousands upon thousands of buttons, you're very unlikely to come anywhere close to running out.
Does this help? Looks like you would have to handle the OnPaint event, and not take focus...
The regular .net 2.0 button supports part of what a TSpeedbutton Does:
The Glyph: Image
Flat : FlatStyle
It does not handle:
Down
Group
These two are related, you could inherit from the button, and ownerdraw it, adding Down and Group features.
Codeproject has an example of ownerdraw buttons.

Categories

Resources