I've encountered a Oracle Form which has a strange behavior. It seems that it looses the spanish character "ñ" when converting it from Oracle 10gR2 to Oracle 11gR1. This only seems to happen in Text Field Prompts. The rest of the elements in the form seem to display the characters properly. Any suggestions as to what might cause this or what to check to fix it? I've already have checked that the fonts installed support this character and that the NLS related settings look ok.
Well, after a whole day trying to determine what the problem was, it seems that the simplest answer was the right one: The original developer for this form seemed to want to assure that the character was displayed properly and he had a bad setup, so he was setting the text using the SET_ITEM_PROPERTY function, and using the CHR function to escape the character. Something like the following:
SET_ITEM_PROPERTY('BLOCK.PASS_FIELD', PROMPT_TEXT, 'Contrase'||CHR(241)||'a: ');
That for the prompts for the fields which were titled "Contraseña: " in their properties.
In the current set up, it works, but on this new environmet, we are using an UTF8 encoding and the code for the letter "ñ" changes completely. Just for the sake of completeness the code in utf8 would be CHR(50097). But I suggest it would be better just to ask your DBA or SYSADMIN to fix the NLS settings so you can just use the prompt or field properties and don't have to get this "creative" and make other dev waste too much time.
It never ocurred to me to check for this, because the properties seemed to be set up correctly, but a simple test of creating a new field with the same properties finally showed me that the problem was specific to the 4 fields which were already created and searching for code-based attribute changes led me to find this was the issue. So I leave this answer here in the hope that someone else saves a few hours of his time and checks for the simple answer first.
Related
I have searched for a setting within the mvbasic extension within VSCode but I may have hit a dead end. I am new to using VSCode with the rocket mvbasic extension and still in the learning process, so please bear with me.
Our development for the most part has always been directly on the server using the editor within it to code and develop on a Unix/Aix platform with Unidata. Some of our code has array assignments with CHAR(253)/CHAR(254) characters within them. See the link to the image that shows how its done. Now I didn't do this code, the original software developer did this many many years ago and we just aren't going to go and change it all.
How code looks on actual server
The issue is when pulling the code to edit in VSCode, the extension is changing it, and I uploaded it back and didn't pay attention and it was implemented in our production incorrectly, which created a few bugs.
ALIST="H�V�P�R�M�D"
How code looks in VSCode
How code looks after uploaded back to server from VSCode
Easy to fix, no biggie, but now to my question.
Does anyone have this issue, or has a direction to point me into that maybe I need to create a setting to keep the characters in the correct ASCII format so that this doesn't happen again by mistake?
VSCode defaults to the sane choice for character encoding in 2022: utf-8, but sometimes you have to deal with legacy stuff.
https://code.visualstudio.com/docs/editor/codebasics#_file-encoding-support
If you click on the UTF-8 in the bottom right corner you can choose "Reopen with Encoding":
After that, you can select a different encoding. I chose DOS (CP437) at a guess and literal MV characters are displayed as superscript 2 (²), and for me I can save to the server and confirm those characters remain as #VM after a round trip (though for my terminal emulator they appear as } which is useful).
You can edit preferences and set "files.encoding": "cp437". One other thing that can be helpful if your programs don't have a standard extension (like .bas) as most don't is to set the default mode to basic so most of what you're editing will identify as MVbasic, and you can do a quick CTRL-K M to switch to any other modes if you're just pasting in something else like SQL.
Some useful links - the Rocket forums are helpful and the folks there are always super nice
https://community.rocketsoftware.com/forums/multivalue?CommunityKey=521bce2e-71d5-4d32-b560-dfa95e950eb5
The MV Extensions Community extension is a good group and always has been helpful when I've had issues. I've made some small contributions - they're very open. I prefer this extension, but honestly haven't done a deep comparison.
https://github.com/mvextensions
I'm sharing a small but annoying issue that sometimes pops up when I'm using shortcuts to insert operators while working on a markdown file in R : the operator either does not get written, or even worse gets written on another file.
So let's say I am working on the file "report.rmd", and I want to insert the pipe operator using Ctrl+Maj+M, or the assignment operator using "Alt+-", and I have the file "test.R" opened. Well, I therefore type the aforementioned shortcuts and...nothing happens on my markdown file. But some nice operators that had nothing to do there get written on my test.R file.
The only way I found to solve this problem is to close and reopen RStudio (restarting unfortunately doesn't solve the issue).
While this is quite a minor problem, it's incredibly annoying. Did it ever happen to anyone of you, and if so do you know where it comes from and how to solve it?
Edit:
Although I am still running into this issue (without being able to reproduce it consistently) I came into a somewhat lighter solution. Instead of restarting R, simply closing all tabs (closing just the problematic one doesn't work) solves the problem. I hope this helps narrowing down the possible origins of the problem.
Short Answer
re-define the key combo to Ctrl+Shift+ \ , assuming this does not create a conflict
Background
I've had a similar problem for a while, too. In my case, the shortcut never works. I can not find the source. I even found a conflict with Ctrl+Shift+M assigned to 2 Editor functions.
Image:Screen Capture 2 conflicting hotkey assignments
However, a simple key reassignment of the one that is not the pipe operator ("Expand to Matching")
Image:screen capture showing the hotkey conflict solveddidn't solve the issue in my case.
Solution
Here's what did the job for me
I managed to assign a different combo (that hasn't been assigned yet) and that is comfortable enough in the sense of its location on the keyboard
go to Tools → Modify Keyboard Shortcuts...
In the filter box, write "Pipe"
Direct the cursor to the text box showing the current shortcut, and press the new combo (e.g. Ctrl+Shift+ \ ), then Enter.
Remember to hit Apply
Make sure the new Combo isn't a duplicate of another command, by going back to step 1 and sorting the list by Shortcut, then scrolling down to find your new one. if there is an ovelap, consider changing one of them.
This question involves bending Microsoft Word 2013 to one's will.
I have been asked to help fix a problem with Word 2013's autocorrect.
We are working on a spell checker for my native language (Afrikaans), and many Afrikaans words contain a diacritical/umlaut (ë, ö, Ü, etc).
The spell checker consists of a .dic file which is basically just a text file that contains about 508 000 words, and an autocorrect list (.acl) file that is used to automatically replace text as you type.
The spell checker works very well for the most part. It replaces the text as you type, which is the desired effect. The problem is that autocorrect doesn't work with all words.
For example, if I want to type the Afrikaans word 'pêrels' (which means 'pearls'), I should only have to type 'perels' (without the ^ character on the 'e'), and autocorrect should automatically change it to the correct form.
Same with 'reën' (rain). If I type 'reen' (without the umlaut), it is supposed to automatically correct it.
However, in both of the above cases, the words remain unchanged. A red line appears under the words, and when you right-click, you can select the correct word from the pop-up autocorrect menu as shown in the image below.
As you can see, the correct form of the word is the first one in the context menu. I need autocorrect to automatically change the wrong word into the first word that appears in said menu. It should completely ignore the other menu items, and just go with the first word.
My initial instinct was to manually add the words to the *.acl file using a text editor, but the file is encrypted and not readable (I used Notepad++).
I then tried adding them inside Word's autocorrect options menu. However, Word 2013 has a maximum autocorrect memory of 64KB, and the size of the file is already at that maximum. Whenever I add more words, it bombs out and basically wipes the file contents. This doesn't seem like the most efficient strategy anyway, since I would need to manually enter hundreds, if not thousands of autocorrect cases. Ain't nobody got time for that!
What makes this even more complicated (ironically), is that there is no real "program". In other words, this isn't a C# program with source code that I can manipulate. I have the two files mentioned above, and Word's built-in options (which I have already explored). That's it. Nothing else.
I'm stuck. Does anyone have any ideas?
Is it perhaps possible for me to hack Word to increase the autocorrect memory to, let's say, 128 KB? Google hasn't turned up anything of use.
Or, is there a way to set Word to not give the autocorrect context menu, and instead default to the first matching word in the dictionary, as mentioned above?
I can probably write a batch script, C# program, or edit the registry if need be. I just need to know where to start.
Thanks for any help!
In case you are still looking for a solution, you might consider using AutoHotkey (http://www.autohotkey.com). It is a very powerful free open-source utility, and can handle substitutions similar to AutoCorrect. Whenever the built-in program features of Word and others fail to handle my needs, I use AutoHotkey. It has the added benefit of not being tied to any specific program (e.g., Word), so the substitutions can occur anywhere needed. I hope it helps you. I have used and depended on AutoHotkey for years of new Windows versions, new Office versions, and highly recommend having a look. You might even get new ideas about time-saving automation with AutoHotkey. Good luck!
my client is saying that she couldn't register on our website and getting error
When she was registering, she would enter all the information, and when she would click through, an error message would tell her that the name field only allowed letters and not numbers. She wasn't entering any numbers.
Could this be a problem with her browser? (She is using Internet Explorer.) Her computer? What else could it be?
I tried it, and it worked for me.
i am using regular expression
ValidationExpression="^[A-Za-z]+$".
She might not be entering numbers, but is that all your error message states?
She might be entering punctuation, symbols, or spaces.
Copying and pasting something in could also leave a trailing space which would fail your validation.
Perhaps her name has a hyphen, apostrophe or accented character in it. If it is a full name, then it is probably erroring on the space between the forename and surname!
Avoid restricting what users are allowed to input as you'll usually end up stopping people from entering things that should be perfectly acceptable, just use suitable escape sequences (e.g. with paramertised queries for databases or converting <, >, &, " and ' to their respective entities for HTML) before putting the data anywhere.
I'm assuming you're not a technical person. The chances are that the name entered has and apostrophe, space, or anything that isn't between a-z.
The reason you are getting this message is because whoever created the system has told is to say that when the name doesn't match the regular expression, even though it probably has nothing to do with entering a number.
Ok, I'll say it a thousand times. Never assume what the end user is saying is true or what they claim to be doing is what they actually are doing. Not that they are deceitful, just they often don't know.
I recommend using a remote desktop software such as Co-Pilot (no, I don't work for fogcreek) and connecting to any user that can replicate this issue and view it happening for yourself.
Once you can verify it is indeed happening, you should be able to replicate it from your end and then submit it to the developers (or yourself) to be fixed
I'ts not a browser-related problem. ASP.NET form validation is server-side.
We have a very strange problem in out application, all of a sudden we started noticing
upside down question marks being saved along with other text typed in to the fields on the screen. These upside down question marks were not originally entered by the users and it is unclear where they come from. We are using Oracle 10g with Asp.Net.
Here is an example of the issue: "140, 141) ¿ 16-Oct-07". If any one have seen this before and found a way to fix this please let me know how.
This sounds like a character encoding issue. Please check what encoding your database (tables) are set to, and what encoding the objects or strings which are passing data in the database are of. If there is a mis-match (DB in ANSI, App in UTF-8), these sorts of issues can appear.
Greg, you should check NLS_CHARACTERSET not NLS_NCHAR_CHARACTERSET settings. And I bet you it's WE8ISO8859P1 or something similar and not unicode. The problem occurs when the submitted data in unicode, which is probably UTF8, and Oracle tries to map the characters to WE8ISO8859P1 character set. It does fine for most of them but fails for high ASCII number characters, like 140.
So yes, I have seen the same issue in our application and in our case it was caused by special quote marks (“example”, ‘example’) that were copied from MS Word. Word automatically converts double quotes to some other quotes. The solution was to convert the database to UTF-8.
IF your users are copying from MS Word you can turn the feature off . Its part of the autocorrect/autoformat functionality. If you uncheck the replace options for quotes and apostrophes you should be ok. Be sure turn off the replacements in both the AutoFormat and AutoFormat as you type.