I am trying to create multi line hint in my application made in delphi 10 seattle (FMX). seems like line break is not working while setting the hints.
Button1.Hint := 'Line 1' + #13#10 + 'Line2';
Any idea about how this can be done. this is working fine in VCL though.
please check if your button has ShowHint property checked.
Button1.Hint := 'line 1' + sLineBreak + 'line 2';
I can offer a hint that I just worked through the same type of problem in C++ Builder Rio. I don't have Delphi, just C++ Builder, but the two products are so inter-related, I use hints (or code) from Delphi all the time to solve my problems.
In C/C++, you can generally use "\r" or its equivalent "\n\l" to display a carriage return (which I was trying to display in a TMemo). The TMemo looked like it was just stripping out the codes (except it thought the "\l", for line-feed, was an invalid escape code, so it would display just the "l") and was displaying everything on one line. I did notice the shortcut for tab ("\t") was working.
Again, in C/C++, there are other options for how to create characters. The equivalent of what you are doing, "char(13)+char(10)" just displays the characters "23" with everything on the same line (as you are describing). That is how one add characters when you are using decimal (base 10). If I wanted to use hexadecimal, I would write "\0xd\0xa" (which just gets stripped out of the text and displayed on one line, like the stuff in the second paragraph above).
The solution that I found that worked in C++ Builder was to use an octal notation for my character encoding ("\015\012"). Personally, in about 50 years of programming, I have never previously seen a situation where hexadecimal failed, but octal worked, but I was desperate enough to try it.
For all this testing and debugging, I created a new project, added a TMemo and a button (and set ShowHint=true for the button) to the form and put the following in for the code for the button:
void __fastcall TForm1::Button1Click(TObject *Sender)
{
UnicodeString CR = "\015\012";
Memo1->Text = "a" + CR + "b";
Button1->Hint = Memo1->Text + " (hint)";
}
So, my solution to your problem is figure out how you can put octal codes in for characters and display the corresponding text in Delphi, then use that encoding for the octal characters "015" and "012".
Related
Here's what I know so far:
Browser: Google Chrome 56+
OS: Windows 10
The issue is in the picture, a white box appears inline with the text. When you inspect it the inspector shows a box character. I have tried on Chrome 55 and under and there is no issue. It's on the home page of our site, so people are quickly noticing it. Nothing in IE. Any ideas?
EDIT: Stack Overflow removes special characters, so the code snippet below does not work. See http://codepen.io/dennishall/pen/pRMxbJ for a working example.
EDIT 2: This S.O. post to find non-ascii characters should put you on the right track to find the problem file, if it's in your source code .. if not, it's in the CMS, and you should be able to figure out what record & field is the offender. -- How do I grep for all non-ASCII characters in UNIX
var stringWithSpecialCharacter = "find your";
document.getElementById('example-output').innerHTML = 'regular space char code = ' + stringWithSpecialCharacter.charCodeAt(4) + ' special character code for the following empty space = ' + stringWithSpecialCharacter.charCodeAt(5);
<div id="example-output"></div>
You have a special character in your source code (or CMS). Check your source code. This might be from copy/paste from a Word doc or similar.
Years ago, I was messing around with Visual Basic and I discovered a bug with the MsgBox function. I tried searching for it, but nobody had ever said anything about it. It's not just with Visual Basic though; it's with anything that uses the standard Windows MessageBox API call.
The bug is triggered when the title text has more than one character, and the first character is a lowercase 'y' with an umlaut ('ÿ'). What's so special about this character? It almost definitely not the character itself, but rather its ASCII value that's special. 'ÿ' is character 255 (0xFF), meaning it's the highest value that can be stored in an unsigned byte, and all its bits are set to 1.
What does this bug do? Well, there are two different possibilities, which depend on the number of characters in the title text. If there are an even number of characters (unless it's 2) in the title text, no message box appears, and you just hear the alert sound. If there are two characters in the title text, or any odd number other than 1 (in which case the bug wouldn't be triggered)...then this happens:
And that's not all--the message will also be truncated to one line. It seems like the kind of bug that would occur in at least one semi-high-profile incident, considering how often this API call is used. Are there any reports of this on the Internet, or anything showing what could cause it? Maybe it's a Unicode-related glitch, like that "bush hid the facts" glitch in Notepad?
I made a program in case you want to play around with this; download it here.
Alternatively, copy the following into Notepad, save it with a .vbs extension, and double-click it to display the dialog box seen above:
MsgBox "Windows 3.1 font, anyone?", 0, "ÿ ODD NUMBER!"
Or for a different font:
MsgBox "I CAN HAS CHEEZBURGER?", 0, "ÿ HImpact"
EDIT: It seems that if the first four characters are ÿ's, it doesn't ever display the message, even if there's an odd number of characters.
This is a bug with dialog templates generally. It is not a message box bug as such.
For example, in Visual Studio create the default win32 application. In the .rc file, change the caption in the template for the about box from
CAPTION "About sampleapp"
to
CAPTION "ÿT"
and the bug will manifest itself when you display the about box.
In the DLGTEMPLATEEX documentation note that the menu and class name have type sz_Or_Ord which means either a null-terminated string or 0xFFFF followed by a single word resource identifier.
Windows incorrectly applies a similar scheme to the dialog title: if the first character is 0xFF then it treats the title as being two WORDs long, but only when it is trying to locate the font information. When it is displaying the title it correctly treats the title as a string.
In other words, Windows is looking for the font information inside the title string. In most case this won't specify a valid font, so Windows defaults to the system font.
To prove this, I constructed a dialog template in memory (based on this). Once this was working I deleted the code that writes the font information to the template and used the dialog title "ÿa\xd\x200\x21SimSun". This displays the dialog in italic SimSun because windows is reading the font information from the title string.
This bug is likely a hangover from 16-bit Windows, where (I guess) 0xFF was used as the resource ID marker.
A strange bug. I suspect the symptoms are the result of the way the MessageBox() actually displays the dialog.
Internally, MessageBox() builds a dialog template dynamically. If you look at the description of a DLGTEMPLATE structure you'll find the following nugget of information:
In a standard template for a dialog box, the DLGTEMPLATE structure is
always immediately followed by three variable-length arrays that
specify the menu, class, and title for the dialog box. When the
DS_SETFONT style is specified, these arrays are also followed by a
16-bit value specifying point size and another variable-length array
specifying a typeface name.
So, the in-memory layout of a dialog template has the font specification immediately following the dialog box title.
Visual Basic does not use Unicode and so the function you're calling is actually MessageBoxA(). This is simply a thunk that converts the passed-in strings from multibyte to Unicode and then calls MessageBoxW().
I believe what's happening is that, for some reason, the conversion of that string from multibyte to Unicode is either going wrong, or returning a spurious length value. This has the knock-on effect, when the dialog template is built in memory, of corrupting the memory immediately following the title string - which, as we know, is the font specification.
I am writing a Visual Studio extension which provides intelliSense for a certain content type.
The problem that I am facing now is the effect of "Auto Indent" that Visual Studio provides on empty lines when user types a character.
Here a completion session started on an empty line (over virtual spaces):
Notice the tab symbols on the other lines and no tab on the line with caret on it.
Now when use starts typing, VS automatically and correctly adds necessary tab characters to the line:
Now the problem is those Added tabs apparently become part of the user input and as a result CurrentSession.SelectedCompletionSet.SelectBestMatch() or Filter() method cannot find the current item which starts with "C" here (thinking user has typed \t\tC instead).
If I start the session on anywhere else which does not require auto indent everything works fine.
Any idea?
Edit (more information): I used a code flow very similar to:
Ook here
vsLua here
vsClojure here
In Lua and Clojure you wouldn't face this problem because they never provide intelliSense on virtual spaces (meaning they always start after a certain set of characters) and if you start after a character virtual spaces are already turned into real spaces.
Ook on the other had has the same problem.
Revised Answer:
Ah, I see. I interpreted your question thinking that you were referring to completion triggering via typing, not from the explicit command. If you enable "show whitespace" for the C# editor, you can see what we do here: when you trigger the "show completion" command, we explicitly realize the whitespace so you're no longer floating around in virtual space. You should probably do this as well. (Alternatively, you could detect the scenario and fix it up on the first typing by adjusting your ApplicableTo span, but that's probably not worth the trouble.)
You can get the whitespace that should be inserted from IEditorOperations. So MEF import an IEditorOperationsFactoryService, and then do:
var editorOperations = editorOperationsFactoryService.GetEditorOperations(textView);
var whitespace = editorOperations.GetWhitespaceForVirtualSpace(textView.Caret.Position.VirtualBufferPosition);
if (whitespace.Length != 0)
{
textView.TextBuffer.Insert(textView.Caret.Position.BufferPosition, whitespace);
}
(Funny aside: as I answered this, I was curious to see how we handled this in the Roslyn C# and VB editors. The answer was "not", but filtering still worked by pure luck later in the code.)
Original Answer:
I suspect by your description of the problem that you are implementing your completion like this: you know a character is about to be typed (either via a keyboard filter or IOleCommandTarget) and you trigger an ICompletionSession, where the tracking span is an empty span on the current caret position.
The best approach to fixing this is to not trigger the session before the key is pressed and goes into the editor, but rather after it. This is what we do in the Roslyn implementation for C# and VB completion. Then, when you are in your AugmentCompletionSession call and creating your CompletionSet, compute the "applicable to" span which consists of the non-whitespace characters around your caret. The easiest way to compute this might just be to call GetWordExtent from the text structure navigator.
This allows for other scenarios to work right. Consider scenarios where the user types C, presses escape, and then continues to type your identifier. If you want to trigger completion again, you'd have to do the math to ensure that the "C" is counted as part of your span anyways.
I was going thru some content about control characters especially newline character(will focus on this).After going thru
http://en.wikipedia.org/wiki/Control_characters, got to know that \n is the line character in unix
while it is \r\n in windows. Now i got the question how OS comes into picture when iterpreting
ASCII Codes becoz i was under impression when we type any given character on keyboard, any OS send the same
bits and editor interprets that bit and display the corresponding character. Looks like this understanding is
wrong, Because different bit is sent in case of unix(\n) and windows(\r\n) when we press ENTER(new line terminator).As per
new understanding if we press ENTER on diff OS(say unix and windows),different bits are sent to editor and its
responsibilty of text editor to show the typed stuff in new line keeping the underlying OS in picture.Please let me
know if my understanding is correct as this will help me to understand other basics also?
Next question is if above is correct, what can be the reason different OS treat some control characters differently
when they treat all other characters equally? Is it becoz specific bits are already reserved in specific OS?
How an application treats keyboard input varies a bit, actually. When you press return the application is under no obligation to actually generate LF or CR+LF anywhere. E.g. it might decide to just end the current paragraph object and start a new one (e.g. in a word processor). If it's a Windows text editor then it will probably just write CR+LF into the file, while on Unix it just writes an LF.
They keyboard itself is very, very far removed from things you see on the screen or even on the disk. This goes through scan codes, keyboard layouts and other transformations before it ends up as text or markup somewhere.
Just wondering if anyone knows the keyboard shortcut to swap around two sides of a statement. For example:
I want to swap
firstNameTextbox.Text = myData.FirstName;
to
myData.FirstName = firstNameTextbox.Text;
Does anyone know the shortcut, if there is one? Obviously I would type them out, but there is a lot of statements I need to swap, and I think a shortcut like that would be useful!
Feel free to throw in any shortcuts you think are cool!
My contribution would be CTRL + E, D - this will format your code to Visual Studio standards! Pretty well known I'm guessing but I use it all the time! :)
UPDATE
Just to let everyone know, using a bit of snooping of the article that was posted, I managed to construct a regular expression, so here it is:
Find:
{.+\.Text = myData\..+};
And replace with:
\2 = \1;
Hopefully people can apply this to their own expressions they want to swap!
I think the following thread is a good place to begin with
Invert assignment direction in Visual Studio
Here's how I would go about doing that without a specific keyboard shortcut:
First, select the text you want to modify and replace
" = " with " = "
(the key here is to add a lot of spaces).
If you hold down Alt and use the mouse, you can select a "block" of code. Use this to select only the text on the right side of the equation (it's helpful to add extra white space here in your selection)
Use the same Alt + Left-Click combination to select the beginning of the left side (just select a blank area). You should be able to paste text into here.
If you added extra white space to the text you just added, just should be able to easily insert an = using the Alt + Click technique. Use the same trick to remove the equal sign that's dangling on the right side of your code block.
While this might not do exactly what you're looking for, I've found these tricks quite useful.
If you're using ReSharper, you can do this by pressing CtrlAltShift + ← or →
The feature is in Resharper. Select the code segment and click the content wizard, which is a pencil icon in the left corner reading View Actions List, then choose Reverse Assignment.
It is done.
swap-word is a VSCode extension which sounds like it would do what you want.
Quickly swap places two words or selections...
But I'm not sure if it is compatible with VS.
Since I was not happy with the answers where I need to enter complicated strings into the Visual Studio search/replace dialog, I wrote myself a little AutoHotkey script, that performs the swaps with only the need to press a keyboard shortcut. And this, no matter if you are in VS or in another IDE.
This hotkey (start it once simply from a textfile as script or compiled to exe) runs whenever Win+Ctrl-S is pressed
#^s Up::
clipboard := "" ; Empty the clipboard
Sendinput {Ctrl down}c{ctrl up}
Clipwait
Loop, Parse, clipboard, `n, `r ; iterates over seperates lines
{
array := StrSplit(RegExReplace(A_LoopField,";",""),"=") ; remove semicolon and split by '='
SendInput, % Trim(array[2]) . " = " . Trim(array[1]) . ";{Enter}"
}
return
Many more details are possible, e.g. also supporting code where lines end with a comma
...and I can put many more hotkeys and hotstrings into the same script, e.g. for my most mistyped words:
::esle::else ; this 1 line rewrites all my 'else' typos
I recommend using the find-replace option in Visual Studio. IMHO the REGEX string is not that complicated, and moreover, you don't need to understand the expression in order to use it.
The following regex string works for most programming languages:
([\w\.]+)\s*=\s*([\w\.]+)
For Visual Studio's you want to use $ argument in the replace text.
$2 = $1
Make sure to enable regex.
To do this in one shot, you can select a section of the document, and click the replace-all option.
Before:
comboBoxAddOriginalSrcTextToComment.SelectedIndex = Settings.Default.comboBoxAddOriginalSrcTextToComment;
comboBoxDefaultLanguageSet.SelectedIndex = Settings.Default.comboBoxDefaultLanguageSet;
comboBoxItemsPerTransaltionRequest.SelectedIndex = Settings.Default.comboBoxItemsPerTransaltionRequest;
comboBoxLogFileVerbosityLevel.SelectedIndex = Settings.Default.comboBoxLogFileVerbosityLevel;
comboBoxScreenVerbosityLevel.SelectedIndex = Settings.Default.comboBoxScreenVerbosityLevel;
After:
Settings.Default.comboBoxAddOriginalSrcTextToComment = comboBoxAddOriginalSrcTextToComment.SelectedIndex;
Settings.Default.comboBoxDefaultLanguageSet = comboBoxDefaultLanguageSet.SelectedIndex;
Settings.Default.comboBoxItemsPerTransaltionRequest = comboBoxItemsPerTransaltionRequest.SelectedIndex;
Settings.Default.comboBoxLogFileVerbosityLevel = comboBoxLogFileVerbosityLevel.SelectedIndex;
Settings.Default.comboBoxScreenVerbosityLevel = comboBoxScreenVerbosityLevel.SelectedIndex;
IMHO: It's better for a developer to learn to use the IDE (Integrated Development Environment), then to create new tools to do the same thing the IDE can do.