Square mouse pointer in Visual Studio 2008 designer - c#

A strange issue with Visual Studio 2008. I have a winforms application that contains several forms.
On one of my forms, the mouse pointer has a square shape around the arrow, like in the attached image. I cannot get rid of it, no matter what I tried. The square keeps moving along with the mouse pointer. Seems funny, but it's really frustrating, really, because I cannot use the drag-and-drop functionality at all. This prevents me from working with the designer. Imagine that I cannot grab the edge of any control to resize it. I can move controls, though...
What is particular about this form is that it is derived from another form, like this:
public partial class MyForm : BaseForm
BaseForm is also derived from Form. I'd say nothing too uncommon.
Thanks for any idea.
Later Edit:
I found why I got an error when entering into MyForm's designer.
BaseForm has an Microsoft.Reporting.WinForms.ReportViewer component. The component was added as a private member.
When working with MyForm's designer, VS was automatically generating a new Microsoft.Reporting.WinForms.ReportViewer member for MyForm, so I got 2 members with the same name. One defined in the base class, one in the derived class.
I solved this by declaring the base class's member as public and regenerating the derived class, so no need to duplicate things.
Anyway, unfortunately, this did not solve my designer issue with the mouse cursor...

Chances are that the BaseForm has soe logic in its constructor or other eventhandlers that is supposed to run at runtime but not at DesignTime.
You could use:
if (!this.DesignMode)
{
// runtime only
}
to block out some logic at design mode

Have you tried,
Cursor = Cursors.Default;
or setting it to some other Cursors value?

Related

How to update Templates?

Currently I'm creating a really big project in Visual Studio 2012, where there are some common settings for each form ("Cancel" and "Save" buttons, Methods that change in every form but have the same name, font sizes and types, form color etc.) it will save me a lot of time if I could do all the design a single windows form and when I edit or modify it, have the changes reflected in the other forms as well.
Let's say I need 10 forms, to create them I would choose this default format and have my menu and basic objects already placed and designed; then after 10 forms I decided to move a button a bit, but don't want to go to every form and move it; just change it in the original format, refresh and all my forms will have that button in the new location.
I used Templates as recommended by Can one set the default properties for new WinForms created in Visual Studio?. But I still have the issue that if I change something in the template it won't refresh in every other form created with the template to that point.
I've already thought of changing the InitializeComponent in the WinForm default format, but this is not recommended and I wouldn't want any errors from this later on.
Any ideas?
Thanks in advance
Inheritance will work for your solution.
Create "base" form with all "common" controls
Create new "derived" form and change form to inherit from your "base" form.
If you have some common logic in base form, which need to be "overridden" in derived forms - put it to the virtual method
// Base form
protected virtual void Close()
{
// Base logic
}
private void CloseButton_Click(object sender, EventArgs e)
{
Close();
}
// In derived form - just override "Close" method
protected override void Close()
{
// custom logic - will be executed when "Close" button clicked
}
In base form leave empty space for custom controls. Because you will not be able access baseform controls through designer in derived form.
Another approach - Model-View-ViewModel(MVVM)
- Introduce own UserControl with common controls(view) which have property - instance of ViewModel.(Viewmodel will contains behaviour logic and possibility to change "base" settings.)
- Add this user control to all "derived" forms and set UserControl.ViewModelProperty to instance which will represent logic for this particular form.
Without knowing "full" context of your goals - difficult to suggest more, but I am pretty sure you can build maintainable relations between forms, which can share common logic and view.
No, there is nothing you can do. Once you use a template to create a project or a file, it becomes a one-off. You have to edit it manually, or use a text editor that is powerful enough to employ a find and replace with pattern matching and capture group insertion.

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.

C# WinForms FlowLayoutPanel locking child controls

I have a base form containing some elements like this:
- pnlSearch of type Panel: search button
- pnlActions of type FlowLayoutPanel: add, edit, delete, export.. etc buttons
nothing is locked, both panels' modifiers are Private & buttons' modifiers are Protected
FlowLayoutPanel is used to customize options in the child forms (e.g. removing the delete option) without leaving empty spaces since the elements will flow accordingly.
In a child form, the search button only is accessible. Buttons in pnlActions are locked in the designer but by checking the properties Locked = False and Modifiers= Protected
Tried setting the pnlActions' modifiers to Protected but it's still the same.
Any idea what's causing this behavior?
what's the difference between Panel and FlowLayoutPanel other than inner controls layout?
I'd post code samples if I've hand-coded anything but it's all generated by designer
I'm using VS 2013 on Win7 if that would matter
Thanks in advance
this is a problem of the Designer. if you do your changes via code all work...
The problem won't be resolved because the platform is not mainteined by Microsoft anymore.
I know it's an old question, but I share a possible solution, in case someone needs it.
We will create a class that inherits FlowLayoutPanel, I name it FlowLayoutPanelHeritable. You can place it in the namespace that you consider appropriate, for this example the namespace is WindowsFormsApp.
using System.ComponentModel;
using System.Windows.Forms;
using System.Windows.Forms.Design;
namespace WindowsFormsApp
{
[Designer(typeof(ParentControlDesigner))]
public class FlowLayoutPanelHeritable : FlowLayoutPanel
{
}
}
First we must set the modifiers of the FlowLayoutPanel that is in FatherForm, in Protected. Now we must make a modification by code in FatherForm, accessing FatherForm.designer.cs. We will replace each instance of FlowLayoutPanel, by FlowLayoutPanelHeritable (in the creation, and initialization of variables). Then we save, and recompile.
Now if you access ChildForm, you will see that you no longer have the modification restriction at design time.
Important: if you want to edit FatherForm, you will have to access FatherForm.designer.cs and replace all the FlowLayoutPanelHeritable to FlowLayoutPanel again; When you finish editing, perform the reverse process.

All the controls in visual studio windows form invisible while loading it

In Visual Studio 2010 , while loading a visual c# form, the form comes up, but all the controls in it, and everything has become invisible.
I'm getting the following error:
Warning 1 'EIM.Form2.Name' hides inherited member 'System.Windows.Forms.Control.Name'. Use the new keyword if hiding was intended. C:\Users\Administrator\documents\visual studio
2010\Projects\EIM\EIM\Form2.Designer.cs 1172 44 EIM
Can anyone point me in the right direction?
It's because the base members are not being called. When you declare a Name property in your derivative class, you hide the Name member for your base class. Therefore, when your form is compiled, your derivative will be called rather than the base, and your controls become "invisible".
In addition to what aevitas said I guess the problem only occurs while the form is loading? One reason could be that you're performing some long-lasting action in the Load event of the form. This causes the form to be shown, but everything is either invisible or unusable.
Try putting the code that performs this long-lasting operation into the Shown event, which is called after the form was shown and all controls were initialized.

Prevent Designer from removing Attributes on Control members

I want to mark certain controls on my Windows Form with Attributes. So I added the Attribute in my TestAttributes.Designer.cs:
[AmbientValue(true)]
private System.Windows.Forms.Label label1;
But whenever I change the Modifiers-property of label1 using the properties-window of the designer, the Designer silently removes my Attribute from the declaration:
public System.Windows.Forms.Label label1;
I tried putting the declaration in the TestAttributes.cs to not mess with the .Designer.cs file. But when changing the Modifiers property the declaration is moved back to TestAttributes.Designer.cs and the Attribute is gone.
How can I prevent the Designer from removing my Attributes?
EDIT:
The question should better be: Can I permanently move the declaration of a control out of the *.Designer.cs file, so I can apply an Attribute there? As I wrote above, it gets moved back in some cases.
Thank you!
richn
If you want to keep designer support, I recommend using an external class library.
namespace ClassLibrary1
{
[System.ComponentModel.AmbientValue(true)]
public class TestClass : System.Windows.Forms.Label
{
}
}
You can compile something like this to a class library, and then import it to visual studio. If you don't know how to do that, follow the instructions below.
Right click the toolbox
Click "Choose Items"
Wait. Do not make the mistake of terminating visual studio now.
Select Browse.
Select your dll file.
I normally don't like people who give the "don't do it" answer, but don't do it.
Changing the designer class is dangerous, and can almost always lead to unexpected consequences. The designer code is reserved for the compiler, and it should always look like the compiler expects it to look.
If you really wanted attributes in what would otherwise be your designer code, you should instead make an empty application, and do the forms code yourself. You shouldn't be trying to modify designer code anyway, if you don't understand how to do it from scratch
If that seems like a lot of work, you can always try to use the designer as a model, and then copy that over to a new, non-windows forms project.
Untill recently i was lead to believe that designer was just part of the code and it was not to be touched. I was wrong. Turns out you can rip the entire thing out and then compiler will throw an error at you. Okay, that's fine, just define your own stuff, completely thus eliminating the necessity for a designer. here is how. Say you have a tag
<div id="div1" runat="server">
and you want to make it invisible on the back side without any designer.cs file present (we deleted it). First reference it along with other declarations (i.e. outside of page_load, somewhere on the outside)
protected System.Web.UI.HtmlControls.HtmlGenericControl div1;
Remember however, you MUST reference EVERYTHING that you use on the front side that has a runat="server" tag. So say you have a page with only a runat="server" label, on the back we reference to it as
namespace yournamespace.something
{
public class yourpagetitle: System.Web.UI.Page
{
protected System.Web.UI.WebControls.Image imgLogo;
protected System.Web.UI.WebControls.TextBox tbDate;
protected System.Web.UI.WebControls.Label yourLabelName;
Notice I added image and a textbox as additional examples. And huzza! You have thus completely eliminated the need for designer.cs file. Oh, and do notice, designer.cs file is nothing more than what we just did above, but it does it for you automatically. ...most of the time... When it fails, time to handle things your own way. I'm sure if you reformat your computer, reinstall everything, etc etc etc things will work again, no doubt. This is just a legitimate work around for those who do not have time to babysit and troubleshoot every little hick-up Microsoft does.

Categories

Resources