I am trying to use sqlite3.exe on a computer that has the Korean version of Windows XP. This version of Windows uses the won character (₩) in place of the backslash character in paths (For example, instead of c:\ it's c:₩ ). It seems possible to enter a backslash in text editors like Word, but not in the command line. In fact, even if I copy a backslash character, it is converted to the won character when I paste it in.
Since SQL uses the backslash to designate quotes, I am unable to enter them. Instead of '\"' I end up typing '₩"' which generates an error.
Does anyone know how to force a real backslash to be entered into the command line on this version of Windows?
There is plenty of software written in Korea, so hopefully someone else has had this problem.
Open properties of console window and choose TrueType font in 'Fonts' tab (not sure for Korean, but they commonly are marked with "TT" icon).
Related
Using neovim version v0.8.2 when pasting multi-line text from the system clipboard (not an internal register), the newline characters get stripped away, undesirably resulting in a single line.
Querying the termpastefilter, the value is on the defaults - "BS,HT,ESC,DEL".
When pasting, neovim asks for a confirmation before pasting due to the fact there are control characters in the pasted string and in the confirmation message, part of the text is revealed with the control characters escaped, where one can clearly see the \n characters, however after pasting the string they get stripped.
The terminal emulator is urxvt version v9.31.
How can one undo this behavior?
I've the same "problem" but sad news:
More information would be needed - what are "incorrect line endings" and have
you disabled the confirm-paste plugin? If not, which option did you chose?
Also for some reason when i open the terminal, half the screen is
flushed. This seems to have been reported here already:
Yes, that is a race condition between your wm and urxvt. It can happen
with all terminals and also older versions of urxvt, but happens much
more commonly in the current version. We have plans to address this,
but are not sure what the right course is, yet, as it is not a bug.
A workaround of sorts is to output some newliens so the prompt is at
the bottom (which is where it will end up anyway, under normal use),
or specify a geometry larger than the screen and let your wm shrink
it, which has pretty much the same effect.
Source is the official mailing list which can be found here: http://lists.schmorp.de/pipermail/rxvt-unicode/2023q1/002650.html
As a workaround I will temporary transfer terminator.
I created a project from the "GLFW project" template in CodeBlocks 13.12 and hit F8 to run it. That's all. And what I got is an error as follows:
Cross-platform IDE built around wxWidgets, designed to be extensible and configurable. has stopped working
A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.
(it's using CB's description "Cross-platform ..." as its name here, apparently)
Any ideas?
The path to my project had some Cyrillic characters in it. I fixed it to consist of Latin characters only and the crash went away.
This bug appears also when the path contains Romanian characters like: ă â î ș ț. If anyone sees this answer, just make sure your path contains only Latin characters.
What is the actual encoding used in Access' VBA editor? I have been searching for a concrete answer for quite a while but with no luck.
I thought it was UTF-8 but I'm not very certain.
My main issue is that when writing a query in VBA I sometimes need to test it in Access' query editor. When copy-pasting however, I lose my native characters (greek in my case) as they turn to gibberish.
I have tried pasting in a text editor and saving it as different encodings but I can never recover the original characters.
Thanks in advance.
Edit
Let me explain this a bit further:
As you can see I can write my greek characters in the VBA editor normally:
However, copying the first line in Access' query editor, I get the following:
Same goes for a simple text editor:
So I am inclined to think that the problem lies inside the clipboard, due to the encoding used for the greek characters. I guess they are not Unicode, as I indeed have to make the change in the System Locale for non-unicode characters. So how are these characters saved/copied? In what encoding?
Answer
Actually this problem was solved by switching the keyboard input language to greek (EL), when copying the actual test string.
I am still not sure however, as to why that happens. If anyone can provide some insight into this, I would love to hear it.
Thanks again
The VBA editor does not support Unicode characters, either for input or display. Instead, it uses the older Windows technology called "code pages" to provide support for non-ASCII characters.
So, the character encoding in the VBA editor corresponds to the code page that is used by the Windows system locale as specified in the "Regional and Language Options" control panel. For example, with my system locale set to "Greek (Greece)"
I can enter Greek characters into my VBA code
However, if I switch my Windows system locale back to "English (United States)"
and re-open my VBA project, the Greek characters have changed to the corresponding characters in the new code page
If "Control Panel" -> "Regional and Language Options" -> "System Locale" is set correctly but you still suffer from this problem some times then note that while you're copying your keyboard layout must be switched to the non-English language.
This is applicable to all non-unicode-aware applications not only VBA.
Credit goes to #parakmiakos
details in this: http://www.pcreview.co.uk/forums/use-greek-characters-visual-basic-editor-t2097705.html
Looks like making sure your OS is set properly, and font choice inside the VBA editor.
I had a similar problem with Cyrillic characters. Part of the problem is solved when set the System locale correctly.
However, The VBA editor still does not recognize cyrillic characters when it has to interpret them from inside itself.
For example it can not display characters from the command:
Msgbox "Здравей"
but if the sheet name is in cyrillic characters it does it well:
Msgbox Activesheet.Name
Finally, it turned out that these kind of problems were solved when I changed to 32 bits version of MS Office.
I have installed 2.02 Stable 64 bit version of TeXnicCenter and have following problem with spelling check. In one of my existing LaTeX document the grammar of the text in English is checked correctly and all typos are being underlined. In this file German language is not being recognise although I change setting for the language in the options for spelling. However, in other of my existing LaTex document the spelling tool is not recognising English text but it recognises text in German.
Here some hint: It could be that the other LaTex file has been created within German Windows environment. Now I have the Win 7 environment in English. Is it possible that it is connected with the text formatting? Is it possible to change it? Or is there a different cause?
Some other hint: When I generate a new LaTex file the spelling works fine for both English and German. So it is just the problem with the existing document.
Good hint from your side towards text encoding Phil. Solution is a bit different though. Apparently TexnicCenter is saving .tex files with ANSI encoding as default. As soon as .tex files are saved with UTF-8 encoding, spelling check works fine. There are not options to be set in the program. One has to go through Files->Save As and set the encoding while saving.
I know this is an old topic but here is what solved my issue: manually change the project language. Go to project > properties and then change the language there.
My documentation management app involves converting a .docx file containing non-ASCII Unicode characters (Japanese) to PDF with docsplit (via the Ruby gem, if it matters). It works fine on my Mac. On my Ubuntu machine, the resulting PDF has square boxes where the characters should be, whether invoked through Ruby or directly on the command line. The odd thing is, when I open up the .docx file directly in LibreOffice and do a PDF export, it works fine. So it would seem there is some aspect to how docsplit invokes LO that causes the Unicode characters to be handled improperly. I have scoured various parts of the documentation and code for options that I might need to specify, with no luck. Any ideas of why this could be happening?
FWIW, docsplit invokes LO with the following options line in pdf_extractor.rb:
options = "--headless --invisible --norestore --nolockcheck --convert-to pdf --outdir #{escaped_out} #{escaped_doc}"
I notice that the output format can optionally be followed by an output filter a in pdf:output_filter_name--is this something I need to think about using?
I have tracked this down to the --headless option which docsplit passes to LibreOffice. That invokes a non-X version of LO, which apparently does not have the necessary Japanese fonts. Unfortunately, there appears to be no way to pass options to docsplit to tell it to omit the --headless option to LO, so I will end up patching or forking the code somehow.