I noticed that Resharper adds "No Suggestion" box on new properties in C# classes. Like this:
This "No Suggestion" box does not add anything to the code, only obstructs lines of code below - and that is an annoyance.
Any way to make Resharper not show this box?
You can edit the prop Live Template and remove the macro associated with the $NAME$ variable of the property.
What ReSharper is trying to do is suggest a name for the property, based on the type. If it's a bool property, there's not much it can suggest, but if it's a complex type, such as Address, then it can suggest a name such as Address. Also, if it's a List<Address>, ReSharper will suggest Addresses or List. So, it can be useful.
However, it isn't terribly helpful to show No suggestions - it might be nicer to just not show anything if the list is empty. I've added a feature request you can vote on and track: RSRP-453668
Related
In an Xpage running on Domino 9.0.1 I'm using a rich text control with some custom toolbar configuration using the control's "attr" property as it is described here: https://frostillic.us/f.nsf/posts/quick-and-dirty-ckeditor-toolbar-setup-for-xpages
I added the link toolbar template using
<xp:this.attrs>
<xp:attr name="toolbar">
<xp:this.value><![CDATA[[["Link", "Unlink", "Anchor"]]]]></xp:this.value>
</xp:attr>
</xp:this.attrs>
All three buttons are displayed fine, esp. I'm able to define an anchor link target.
But trying to reference the anchor target I find that the Link dialog is somewhat incomplete as I can't define my link to use a relative target on the same page. I tried entering a reference in the dialog's URL field as #myAnchorId, but that results in a link looking like this:
....
Here's an image of the dialog that pops up from my Xpage when I hit the "URL link" button:
And this is what the dialog looks like that I can test from the CKEditor Samples page:
I'm aware that the samples page uses CKEditor V 4, so the dialog is somewhat different, but even V 3.6 should be able to reference anchor links using the dialog.
I already looked up on the installed ckeditor's version; \DominoData\domino\html\ckeditor\version.txt says:
cke_version=3.6.6.2
cke_revision=20130606-1534
Question is: what's missing here? Do I have to somehow modify the dialog?
Oh my, finally got it to work; #IBM: this feature truly could use some proper documentation! I'll mark this answer as a community wiki.
Indeed a different dialog is used here, which btw appears to apply to all the dialogs in use with Domino's CKEditor implementation. The trick in my case is to use one of the custom toolbar items instead of the standard one; up to now I found three of those customized items:
use MenuLink instead of the standard Link item; this item
consists of two sub items ('URL Link' and 'Anchor Link'), each calling its own dialog version; the resulting toolbar definition then looks like this: ['MenuLink', 'Unlink', 'Anchor']
use MenuPaste instead of the standard Paste item; again, this
item consists of two sub items ('Paste' and 'Paste as text'), again
each calling its own dialog version
use LotusSpellChecker to add IBM's own spell checking feature, where CKE's standard spell checker isn't working
I found hints to those three custom items inside my local \DominoData\domino\html\ckeditor\config.js. Don't know if those are all custom items available to day.
EDIT:
IBM's Domino Designer Xpages User Guide mentions another means of customizing the toolbar; the section unfortunately is incorrect in describing the options for the toolbarType attribute: be aware that all named types must start with capital letters, e.g. Basic, Slim, Medium, Large, Full, while the also mentioned Lite type isn't working at all; mistyping or using a non-existing value results in the editor not being displayed at all.
The link dialog that you're using is not the default one, so you should check how to modify it or replace it with the default one.
Some coding books mention that we should not prefix the type in the name, since current IDEs are able to make these visible and clear. I completely agree for primitive types but I'm inclined to still prefix my GUI components variable names.
What are the best practices when working with on GUI code regarding GUI component variable naming?
E.g. should I name my
Button btnSubmit
TextField tfName
Checkbox cbActive
or
Button submit
TextField name
Checkbox active
I find that generally, when naming GUI-components, prefixing the variable name with the type of GUI-component simplifies the process of writing code in that when I write code that references them, I don't have to remember the exact name of each component. E.g. often I know that I'm gonna get the text from a specific TextBox, but I don't remember the exact name of it. I start typing TextBox and up in IntelliSense a range of TextBoxes appear, from which I easily can identify the exact one I'm in need of.
Regarding if it's any best practices; It depends on
If your company has any standards, I'd assume they'd be the best practices in this case.
If it's a private project, go with what you feel is the best.
My 0.02$
After tinkering and modifying a GUI I have been working on for some time I ended up with a group of EditControllers and Radio Buttons that I do not need any more, so I would like to get rid of them. However, if I simply delete them from the GUI edit, I get assertion errors. How am I supposed to get rid of these elements?
You need to remove all code from your program that refers to the deleted controls. For each control you want to delete, take its ID and search the source for statements that refer to it.
Start like this:
Check the ID of that given control. Copy it. Now remove the control from dialog resource.
Ensure that ID is not used by other dialogs. If not, you can use following.
Delete that ID from resource.h.
When you compile it, you'd get error (around GetDlgItem, DDX_Control etc). Remove or comment them. Remove appropriate CWnd-derived variables (like CEdit, CComboBox etc).
You are done!
If given ID is used by other dialogs (check it from Resource View's context menu Resource Symbols...), then you cannot directly remove it from resource editor. You, however, need to remove it from appropriate implementation file (of CDialog/CPropertyPage-derived class).
I've created a derived WinForm textbox control that knows how to provide a hint (those grayed out words that say things like "Password" or "Enter search here") as well as allowing for the beep on enter to be disabled.
I have two public properties BeepOnEnter, and HintText, a single method - ResetHint and then overrides for the Text property, the OnGotFocus event and the OnKeyPress event.
This code works fine until I have a need for a textbox on a tool strip also known as a ToolStripTextBox.
I'd like to use the same code for both the TextBox AND the ToolStripTextBox. Is there a way minimize/reduce redundancy? I definitely need code that has classes that are derived from TextBox and ToolStripTextBox so the ui designer allows me to drop these new controls on a form or tool strip but can't figure out how to do it in an OO way.
ToolStripTextBox is derived from ToolStripControlHost and TextBox is derived from TextBoxBase and as multiple inheritance is not allowed, you will be best off creating a 3rd utility class and putting all similar functions in it. You can then leverage an instance of this class in your derived controls to get the common functionality you want.
Which approach do you all think is better?
Next to each field, highlighting each field in a distinctive color or with an easily distinguishable mark, so it's self evident where the problems are, especially on a long form. Also place a help icon next to each failure providing more information in case it's needed by some users. In addition, do not forget to preserve the data that's correct in between failures.
I put a summary of the errors at the top of the form that gives details as to why a field value is incorrect such as "Field1 is Required and must be an integer". I also add visual indicators on the field that errored, typically an asterisk next to the field or changing the color of the input area.
It will always depend on the situation, but...
I prefer to do a non-obtrusive indicator (* perhaps) beside each field and show more detailed messages or a summary message at the top (or bottom) of the form with longer forms.
If the form is shorter, you can probably get away without providing a "summary". I changed my mind on this, you should probably provide a summary.
Identifying the field with an error is important, definitely. However, a summary at the top letting the user know that there are errors below can be helpful for a long form. Additionally, you can put more details in the top summary section that you might not have room for below.
We supply a small indicator next to each field with an error. When you roll over the indicator a tool tip gives you what needs to be fixed. We then also give a summary at the smae time so they can see all of the errors they need to fix.