I have a report containing an inserted picture.
There is a specific portion of the picture I wish to eliminate; in a sense, I want to 'erase' a portion of some text that is in the picture.
And, ultimately, I would like the option to insert a text box and do a 'custom replace' of that text within the picture.
So far, I inserted a text box with some text, but the picture shows through and I see double text.
The best option for you would be to edit the file that was originally used to insert the picture into your report. This will require some kind of editing software though. Once you have made the edits to the original picture, you may then remove the inserted picture from your report and then insert it anew using the new version of the picture.
If editing the image is not an option you could effectively cover up a portion of the picture using a Text Box object. However, by default a text box object will have no background color set, which makes it transparent. This is why you see the image behind the text box you inserted into your report. If you right click the text box and then select "Format Text" to open the Format Editor window. Then go to the "Border" tab in the Format Editor window and click the check "Background" checkbox in the Color group, then use the drop-down to select the background color for your text box object. You will likely want to use white as the background color unless your report has some other background color you need to match.
When I want to display a dataframe inline I never know which of the two formats it will appear as. For instance, mtcars often appears as:
Other times the dataframe will be formatted with up-down and left-right scrolling options.
Is there anyway to control this output style?
I've updated my RStudio version to 1.1.456 and tried paged.print=FALSE in the chunk options but cannot make the scroll view appear.
The code chunk option paged.print controls this behavior. You can change it by writing the argument yourself, or you can click the gear icon for a code chunk and select/deselect the option there:
I have some text in CKEditor which should be editable and some text which should be non-editable.
The non-editable text I am enclosing in a span as below.
<span contenteditable="false" unselectable="on">Here is where my non-editable text goes</span>
The editable text I am enclosing in a span as below.
<span style="background-color:Yellow">$[insert Date]</span>
Here we are using style background yellow to highlight the editable text in yellow to the user.
I put my cursor within the editable text and move using the left or right arrow keys. Once I move outside the editable text area, I am able to remove even the non-editable text using backspace.
The issue is that as soon as my cursor moves outside the editable text area the code isn't able to detect any key press due to which I am not able to restrict the backspace or delete.
Does Range functionality help in this issue? If yes please help and give an example of where we can use the Range code.
EDIT:
It came to my attention that there is a $nonEditable dtd descriptor that could also come in handy:
https://docs.ckeditor.com/ckeditor4/latest/api/CKEDITOR_dtd.html
https://ckeditor.com/old//forums/CKEditor-3.x/Forcing-custom-element-be-BLOCK-level-element
PREVIOUS:
You could use the widget functionality to make the text ineditable-- using contenteditable="false" in CKEditor can be a bit unpredictable, but the creating a widget extension plugin can have really nice results.
It would be a very basic widget that simply uses the upcast checking if the element has 'unselectable="on"', then the text will automatically become uneditable and using the arrow keys will simply skip over the text instead of entering it. You also get quite a bit of other functionality with the widget plugin and it makes it much easier to integrate into things like events, dialog editing, etc.
You can get a widget creation tutorial here:
https://docs.ckeditor.com/ckeditor4/latest/guide/widget_sdk_tutorial_1.html
For more information, I just answered a question about making parts ineditable here:
How can I create uneditable fields on CK Editor?
I am designing a search text box, with close button at the end(will be shown when TextLength > 0).
But when entering lengthy text, the close button hide the last part of text. I need to restrict the text to not cross the close button.
Note: I dont wont to restrict the MaxLength of characters, but the max length of characters to be displayed inside the textbox.
It appears that the close button is overlapping the search text box.
If you are using MFC, then you can use CEdit::SetRect to set the formatting rectangle of edit text. If not MFC, then use EM_SETRECT message to do the same.
I have done similar stuff in my article here: http://www.codeproject.com/Articles/15043/iTunes-like-Find-Edit-Control
When should I put ... at the end of a menu item? I seem to remember reading some rules but can't for the life of me find them.
For context - I'm adding a properties option to a right click menu and am wondering if it is appropriate to add them.
As I understand it it indicates that the option will ask you something else before actually doing anything. The 3 dots are actually called an ellipsis, and if you check out the English use it kind of makes sense:
http://en.wikipedia.org/wiki/Ellipsis
BTW I've noticed OpenOffice breaks this convention sometimes!
When the option will send the user to some sort of dialog where the user has to do something before a real change is made. Options without the ellipse take effect immediately.
For example, 'Save' doesn't have an ellipsis, while 'Save As...' does because the user has to input the new name/location of the file.
One exception to the first two answers: if the whole point of the menu command is to open a window or dialog, then you don't need an ellipsis. For example, a "Get Info" or "Properties" command shouldn't have it, even though it's opening a window which lets you edit things.
It's only when the menu command's purpose is to do something else, but it needs a dialog or confirmation in order to do it.
It means that there will be another dialog box after you select that option, it won't actually 'do' anything. There will be another prompt.
To be exact, the rule is that if more information is required from the user to complete an action, then include an ellipsis. In the MS Vista User Experience Guidelines, getting a confirmation qualifies as "more information" (see http://msdn.microsoft.com/en-us/library/aa511502.aspx). Commands to show Properties, About, Help, Options do not get ellipsis because no further information is needed to execute the command, which is "Show Properties" or "Show Documentation" or "Show Options." The File Open command gets an ellipsis because additional information is needed to open the file, namely the file name.
If the menu is an action that the user will be doing, but the action won't be completed until we get more information from the user, you show an ellipsis, e.g.:
Format Hard Drive… (we need to know which one, and the file system type)
Save As… (we need to know what filename and type to save as)
Print… (we need to know what printer and quality settings)
Find… (we show a text box asking for the text to search for, and where)
Rename… (rename to what)
As opposed to actions that will happen the moment you click the menu item, e.g.:
Save
Undo
Redo
Select All
Ellipses don't just indicate that a dialog will appear. i.e. if it's not an "action", then there's no ellipses, e.g.:
About Gizmo
Page Setup
Print Preview
Options
File Properties
And asking the user if they want to do something does not count as "getting more information from the user", e.g.:
Delete File
Recycle File
New Text Document
Whenever selecting that item results in another dialog box appearing. For actions that happen immediately (think Save vs. Save As), no ellipsis.
Originally, it meant:
An ellipsis (...) after a menu item means that after the item is chosen, the user will be asked for more information before the operation is carried out. Usually, the user must fill in a dialog box and click and OK button or its equivalent. Don't use the ellipsis when the dialog box that will appear is merely a confirmation or warning (for example, 'Save changes before quitting?').
(Apple Human Interface Guidelines, page 69)
Note that it did not mean "show a dialog box", even though that was often the consequence of this. For example, on Mac OS (not X), the "Options" button in the Page Setup window had no ellipsis, even though it showed a modal dialog box. No ellipsis is used because showing the options window is the operation.
(Tog on Interface, pages 46-47)
Of course, these days nobody cares about such things as human interface guidelines, not even Apple, so you can pretty much do what you want and still be more consistent than most any other application out there.
I've usually seen it in places where more input is required from the user before completing an operation. If your properties dialog is allowing the user to change properties, I would include the ellipses. If it's just displaying the information, don't include it.
It generally means that a Dialog will be shown when the item is clicked.
They usually signify that clicking on that entry will open a dialog window.
You should add ellipses to the end of text only if you're truncating the text (this applies anywhere). You should truncate the text if it's too long to reasonably fit where you're putting it.
Edit: interesting, I never noticed that menus in Windows use the ellipses to indicate truncated text, but also use the ellipses on short text to indicate that more information will be collected before the action is taken. This is inconsistent interface design, but since menus are under the control of individual programmers it's unavoidable.
It usually means it'll take your focus away from the current window. Like for example, notepad has a "Find..." which means you're going to focus on another window (ie dialog box) to enter something. But in firefox, it has just "Find" which then focuses on a text input on the same window.