Related
Alright so I'm needing some help here. I working with Outlook 2007 PIA (Outlook add-in) and using the advanced search. I'm trying to write a DASL filter for the AppointmentItem property GlobalAppointmentID but I cannot seem to find the correct namespace to use in the filter.
I've tried urn:schemas:calendar:uid and I do not get any results when searching on the first appointment in the default calendar list. The MSDN documentation states that this is a mapi property but I am unfamiliar with mapi so at the moment I do not know how to even find it in the msdn that way (I tried and ended up way over my head).
I know there is a work around to go to the default folder and iterate through the collection to find the object that I need but I consider that too inefficient (I'm using it at the moment but want to improve it).
Any help would be appreciated!
OOM will not let you search for GlobalAppointmentId (or any other PT_BINARY property) in Items.Find/FindNext/Restrict. The only workaround is to either loop through all item in the Calendar folder (extremely inefficient) or search using Extended MAPI (C++ or Delphi only) or Redemption (I am its author - any language, its version of RDOFolder.Items.Find allows to search on GlobalAppointmentId or any other binary property)
Not every property can be used in a filter string for Items.Restrict, Table.Restrict or Application.AdvancedSearch methods. For both Jet and DASL queries, you cannot restrict on a binary property such as EntryID or GlobalAppointmentID. Also you cannot restrict or search for computed properties.
Anyway, you may find the Chapter 11: Searching Outlook Data helpful.
I have a model in Modelica language (platform: Dymola). Dymola creates a binary file of model during compiling/translation (dymosim.exe). If binary code export licence is available then a binary file which is standalone representative of original dymola model is created. This can be run on any computer without Dymola licence.
Now, My question is how can I create Gui for around this executable file with following requirements:-
1. It should be able to change in some input parameter values.
2. It should be able to get some output parameter values.
Now as background:-
dymosim.exe takes parameter values as input from text file (dsin.txt) and writes output in another text file (dsres.txt)
Specifically, if one has such binary executable which takes input from a text file and writes output in specific format (of which rules are known) to another text file; then what are some tools to create gui for it?
Look into Dymola's embedded server support (DDE/OPC). Since you are using dymosim.exe, I believe you are using Windows so Dymola's restriction on only Visual Studio 32-bit code for embedded servers will be acceptable. (Most Modelica tools have similar embedded servers, but I don't think they are compatible.)
Dymola dymosim.exe exports its time series results as *.mat files, you should be able to find tools/libraries to handle *.mat format in your GUI.
Also, dsin.txt has its own format, you can try to understand it first (try to find its comments) and then parse it, it's not a text file with random string and number columns.
To use FMI standard is worth to consider in the co-simulation mode which means that a solver is included. Dymola allows to export model as FMU package (in Windows platform it is single DLL with some metadata, in Linux platform it is .SO library) and provides these functions worth to do your steps:
fmiSetReal() will set a parameter value
fmiDoStep()
fmiGetReal() will get the variable value
You can call these functions directly, just unzip FMU package and find the DLL inside and link it directly to your application.
Or recommended way (we did it in our app): use FMI Library providing general C API interacting with a FMU package and controling temporal structures the way you need.
Windows Vista introduced the concept of three pseudo-locales:
Pseudo Locale Locale Name LCID
=================== =========== ======
Base qps-ploc 0x0501
Mirrored qps-mirr 0x09ff
East Asian-language qps-asia 0x05fe
Enabling the Base locale is useful, because you can check that your application is using the current locale for formatting of items such as dates, times, numbers, money.
For example when the current locale is set to Base, a date will be formatted as:
[Шěđлеśđαỳ !!!], 8 ōf [Μäŕςћ !!] ōf 2006
Builds of Windows are actually done in pseudo, and then localized into english:
Engineering Windows 7 for a Global Market
Pseudo-Localization
To prevent common globalization bugs, pseudo-localized builds were created. Pseudo-localization is a process that creates a localized product in an artificial language. That language is identical to English except that each character is written with a different character that visually resembles the English character. Except for being entirely machine generated, we create the pseudo-localized builds exactly the same way as we create the localized builds. Because even monolingual US software developers can read pseudo-localized text, it has proven to be an excellent way to find globalization problems early in the development cycle. In the Windows 7 beta, some UI elements were still in their pseudo-localized form, causing some interesting theories about what the meaning might be. We hope we have solved the mystery with this blog post. :-)
Control Panel Dialog in Pseudo-localized Windows 7
Another value in the use of these locale's: it tests that your application doesn't assume that a 16-bit PRIMARYLANGID is made up of an:
8-bit primary language id
8-bit sublanguage id
when in reality a PRIMARYLANGID is:
a 10-bit primary language id
a 6-bit sublanguage id
or graphically:
+-----------------------+-------------------------+
| Sublanguage ID | Primary Language ID |
+-----------------------+-------------------------+
15 10 9 0 bit
These three pseudo-locale's finally walk off the end of the 8th bit (something that Microsoft has been weary of doing for breaking buggy applications).
How do i enable pseudo-locale's in Windows?
See also
MSDN: Pseudo-Locales
MSDN: Using Pseudo-Locales for Localization Testing
MSDN Blogs: Pseudo Locales in Windows Vista Beta 2
MSDN Blogs: One of my colleagues is the "Pseudo Man" (a rich source of puns in conversation!)
MSDN Blogs: Walking off the end of the eighth bit
How do i enable pseudo-locale's in Windows?
Initially the four pseudo-locale's are not visible in the Control Panel: (archive.org)
Note that NLS does not automatically enumerate the pseudo-locales or expose them in the regional and language options portion of the Control Panel. They are only enumerable if values are set in the registry.
You enable them by adding some registry keys:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Nls\Locale]
"00000501"="1" // qps-ploc (Windows Vista and later)
"000005fe"="7" // qps-ploca (Windows Vista and later)
"00000901"="1" // qps-Latn-x-sh (Windows 10 and later)
"000009ff"="d" // qps-plocm (Windows Vista and later)
Which can be done in RegEdit:
Then you can go to Regional and Language Options in the Control Panel:
and select the pseudo-locale:
The three different pseudo-locale are for testing 3 kinds of locales:
Base The qps-ploc locale is used for English-like pseudo localizations. Its strings are longer versions of English strings, using non-Latin and accented characters instead of the normal script. Additionally simple Latin strings should sort in reverse order with this locale.
Mirrored qpa-mirr is used for right-to-left pseudo data, which is another area of interest for testing.
East Asian qps-asia is intended to utilize the large CJK character repertoire, which is also useful for testing.
Warning: Do not try to change the "System Locale":
to a new pseudo-locale:
Otherwise after the reboot:
Windows will fail to start:
And the only fix will be to manually edit the registry from the Recovery Console; restoring the old en-US locale.
Warning
Use of pseudo-locales is used to find localization bugs in software. Unfortunately this will also let you find bugs in other people's software; including Microsoft's:
SQL Server Management Studio1 crashes when presented with other locales (Microsoft Connect):
Microsoft Excel will no longer let you enter functions (the comma used to separate parameters no longer works)
Visual Studio will no longer let you edit comma separated properties
The SQL Server Management Studio diagram designer reports an error
.NET has a bug in the date and time formatting, showing 22////11////2011 4::::42::::53 P̰̃M]
Windows Event Viewer:
Task Scheduler:
SQL Server Management Studio:
Good luck with getting Microsoft to dogfood their own product.
110.50.1617.0
Update 4//10/2012:
Trying to Edit top 200 rows of a table in SQL Server Management Studio:
Executed SQL statement SELECT TOP (200) ...
Error Source: Microsoft.SqlServer.Management.DataTools
Error Message: Object reference not set to an instance of an object
Is fixed by changing Negative sign symbol from -- to -.
Bonus Reading
Pseudo Locales in Windows Vista Beta 2 (archive.is)
How do you test your app for Iñtërnâtiônàlizætiøn? (Internationalization?)
Michael Kaplan: One of my colleagues is the "Pseudo Man" (a rich source of puns in conversation!) (RIP) (archive.is)
https://en.wikipedia.org/wiki/Pseudolocalization
MSDN: Using pseudo-locales for localizability testing archive
You can also change Internet Explorer's Accept-Languages to request qps-ploc language:
You can use this to test that your web-site supports psuedo-locale, and check any missing localizations:
You can see i missed two bits of text in this sample web-site.
It looks like rather than fixing the localization bugs in .NET, SQL Server, Excel, etc, Microsoft changed the Pseudo locale in Windows 10 to mask the bugs:
Item
Windows 7
Windows 10
Locale Identifier
0x0501 (1281)
0x0501 (1281)
Locale Name
qps-ploc
qps-ploc
Example Number
--123,,4567,,8901
-123,,4567,,8901
Example Currency
--$$123,,4567,,8901..00
-$123,,4567,,8901.000
Example Float
--123,,4567,,8901..00
-123,,4567,,8901.000
Example Date
9//08//2015
9/8/2015
Example Time
9::51::17 АΜ
9:45:09
Example DateTime
9//08//2015 9::51::17 АΜ
9/8/2015 9:45
LOCALE_SLANGUAGE
Pseudo Language (Pseudo)
Pseudo (Pseudo)
LOCALE_SENGLANGUAGE
Pseudo Language
Pseudo
LOCALE_SDECIMAL
..
.
LOCALE_SCURRENCY
$$
$
LOCALE_SMONDECIMALSEP
..
.
LOCALE_SDATE
//
/
LOCALE_STIME
::
:
LOCALE_SSHORTDATE
d//MM//yyyy
d/MM/yy
LOCALE_STIMEFORMAT
h::mm::ss tt
H:mm:ss
LOCALE_ITIME
0
1
LOCALE_ICENTURY
1
0
LOCALE_SNEGATIVESIGN
--
-
I can understand not wanting to fix your bugs, because you're lazy it's too hard. But you should have been forced to wear your shame for all to see.
Instead you cop-out and try to hide your failure. That's just bad.
Windows 10 1803
Unfortunately, as of Windows 10 1803, it appears to no longer be possible to enable these locales: archive
For Windows 10, version 1803, editing the Windows Registry like this has no effect. But you can still call the non-enumerating NLS APIs with the names of the pseudo-locales (see the code examples above) to populate your user interface (UI).
According to Unable to use psuedo locales after 1803 Win 10 update archive
Hi all, I broke how the pseudo locales enumerate, my bad, very sorry about that :(
Note that they still work as they are built-in to Windows, “just” that they don't show up in the enumeration - so they don't show up in the drop down - so that makes them a bit trickier to use. I'm working to find a workaround.
Basically, if you copy the registry values from Computer\HKEY_CURRENT_USER\Control Panel\International (not the subkeys) from a machine using the appropriate pseudo locale, then that should be used for further processes, even if it is not enumerated.
Shawn Steele (MSFT)
[Шěđлеśđαỳ !!!], 18 ōf [Јúłў !!] ōf 2018
Registry values for manual config
Here are the exported values from a 1607 system. They can be put into a .reg file for easy import.
If using a .reg file, the following header is required:
Windows Registry Editor Version 5.00
Pseudo (Pseudo) [qps-ploc]
HKCU_Control Panel_Internaltional - qps-ploc - W7.reg (before MS gave up on fixing their localization bugs)
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Control Panel\International]
"Locale"="00000501"
"LocaleName"="qps-ploc"
"s1159"="АΜ"
"s2359"="P̰̃M]"
"sCountry"="Pseudo"
"sCurrency"="$$"
"sDate"="//"
"sDecimal"=".."
"sGrouping"="4;0"
"sLanguage"="ENU"
"sList"=",,"
"sLongDate"="dddd, d 'ōf' MMMM 'ōf' yyyy"
"sMonDecimalSep"=".."
"sMonGrouping"="4;0"
"sMonThousandSep"=",,"
"sNativeDigits"="0123456789"
"sNegativeSign"="--"
"sPositiveSign"="++"
"sShortDate"="d//MM//yyyy"
"sThousand"=",,"
"sTime"="::"
"sTimeFormat"="h::mm::ss tt"
"sShortTime"="h:mm tt"
"sYearMonth"="MMMM yyyy"
"iCalendarType"="1"
"iCountry"="61"
"iCurrDigits"="3"
"iCurrency"="0"
"iDate"="1"
"iDigits"="3"
"NumShape"="1"
"iFirstDayOfWeek"="0"
"iFirstWeekOfYear"="0"
"iLZero"="1"
"iMeasure"="1"
"iNegCurr"="1"
"iNegNumber"="1"
"iPaperSize"="1"
"iTime"="0"
"iTimePrefix"="0"
"iTLZero"="0"
Pseudo (Pseudo Asia) [qps-ploca]
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Control Panel\International]
"Locale"="000005FE"
"LocaleName"="qps-ploca"
"s1159"="午前"
"s2359"="午後"
"sCountry"="Pseudo Asia"
"sCurrency"="¥"
"sDate"="/"
"sDecimal"="."
"sGrouping"="3;0"
"sLanguage"="JPN"
"sList"=","
"sLongDate"="yyyy'年'M'月'd'日'"
"sMonDecimalSep"="."
"sMonGrouping"="3;0"
"sMonThousandSep"=","
"sNativeDigits"="0123456789"
"sNegativeSign"="-"
"sPositiveSign"=""
"sShortDate"="yyyy/MM/dd"
"sThousand"=","
"sTime"=":"
"sTimeFormat"="H:mm:ss"
"sShortTime"="H:mm"
"sYearMonth"="yyyy'年'M'月'"
"iCalendarType"="1"
"iCountry"="81"
"iCurrDigits"="0"
"iCurrency"="0"
"iDate"="2"
"iDigits"="2"
"NumShape"="1"
"iFirstDayOfWeek"="6"
"iFirstWeekOfYear"="0"
"iLZero"="1"
"iMeasure"="0"
"iNegCurr"="1"
"iNegNumber"="1"
"iPaperSize"="9"
"iTime"="1"
"iTimePrefix"="0"
"iTLZero"="0"
Pseudo (Pseudo Mirrored) [qps-plocm]
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Control Panel\International]
"Locale"="000009FF"
"LocaleName"="qps-plocm"
"s1159"="ص"
"s2359"="م"
"sCountry"="Pseudo Mirrored"
"sCurrency"="ر.س."
"sDate"="/"
"sDecimal"="."
"sGrouping"="3;0"
"sLanguage"="ARA"
"sList"=";"
"sLongDate"="dd/MMMM/yyyy"
"sMonDecimalSep"="."
"sMonGrouping"="3;0"
"sMonThousandSep"=","
"sNativeDigits"="٠١٢٣٤٥٦٧٨٩"
"sNegativeSign"="-"
"sPositiveSign"=""
"sShortDate"="dd/MM/yy"
"sThousand"=","
"sTime"=":"
"sTimeFormat"="hh:mm:ss tt"
"sShortTime"="hh:mm tt"
"sYearMonth"="MMMM, yyyy"
"iCalendarType"="23"
"iCountry"="966"
"iCurrDigits"="2"
"iCurrency"="2"
"iDate"="1"
"iDigits"="2"
"NumShape"="0"
"iFirstDayOfWeek"="5"
"iFirstWeekOfYear"="0"
"iLZero"="1"
"iMeasure"="0"
"iNegCurr"="3"
"iNegNumber"="3"
"iPaperSize"="9"
"iTime"="0"
"iTimePrefix"="0"
"iTLZero"="1"
Pseudo (Pseudo Selfhost) [qps-Latn-x-sh]
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Control Panel\International]
"Locale"="00000901"
"LocaleName"="qps-Latn-x-sh"
"s1159"="AM"
"s2359"="PM"
"sCountry"="Pseudo Selfhost"
"sCurrency"="J$"
"sDate"="/"
"sDecimal"="."
"sGrouping"="3;0"
"sLanguage"="ENJ"
"sList"=","
"sLongDate"="dd MMMM, yyyy"
"sMonDecimalSep"="."
"sMonGrouping"="3;0"
"sMonThousandSep"=","
"sNativeDigits"="0123456789"
"sNegativeSign"="-"
"sPositiveSign"=""
"sShortDate"="dd/MM/yyyy"
"sThousand"=","
"sTime"=":"
"sTimeFormat"="HH:mm:ss"
"sShortTime"="HH:mm"
"sYearMonth"="MMMM, yyyy"
"iCalendarType"="1"
"iCountry"="1"
"iCurrDigits"="2"
"iCurrency"="0"
"iDate"="1"
"iDigits"="2"
"NumShape"="1"
"iFirstDayOfWeek"="6"
"iFirstWeekOfYear"="0"
"iLZero"="1"
"iMeasure"="0"
"iNegCurr"="1"
"iNegNumber"="1"
"iPaperSize"="1"
"iTime"="1"
"iTimePrefix"="0"
"iTLZero"="1"
For example, when using entity.name in NSPredicate, I needed to change setFetchPredicate to setFilterPredicate, the 1st one was working just fine with XML store, SQLite required 2nd one.
I found: this message but couldn't find anything related in the list archive.
Is there any list with all valid NSPredicate statements?
When garbage collection can cause troubles?
See the section titled "Fetch Predicates and Sort Descriptors" of the Core Data Programming Guide for SQLite-specific limitations.
I'm not aware of any Core-Data-specific limitations in a Garbage-Collection-enabled environment - the reference in the e-mail you posted is news to me. A quick Google search revealed this thread and it's the first I'm hearing of this issue. I certainly never encountered it despite having a similar setup in a compute-intensive app that used Core Data + SQLite store type.
You'll need to be a lot more specific about your first question, however. I'm not sure what you mean.
Does anyone know what culture settings Win32 uses when dealing with case-insensitive files names?
Is this something that varies based on the user's culture, or are the casing rules that Win32 uses culture invariant?
An approximate answer is at
Comparing Unicode file names the right way.
Basically, the recommendation is to uppercase both strings (using CharUpper, CharUpperBuff, or LCMapString), then compare using a binary comparison (i.e. memcmp or wmemcmp, not CompareString with an invariant locale). The file system doesn't do Unicode normalization, and the case rules are not dependent on locale settings.
There are unfortunate ambiguous cases when dealing with characters whose casing rules have changed across different versions of Unicode, but it's about as good as you can do.
Comparing file names in native code and Don't compare filenames are a couple of good blog posts on this topic. The first has C/C++ code for OrdinalIgnoreCaseCompareStrings, and the second tells you how that doesn't always work for filenames and what to do to mitigate that.
Then there are the Unicode problems. While these new OrdinalIgnoreCase string comparison algorithms are great for your local NTFS drive, they might not yield the right answer on your FAT drive, or a network share.
So what's the answer? When possible, let the file system tell you. CreateFile can tell you if a given filename exists. Just pick the right creation disposition. If you need to compare to handles, you can often use GetFileInformationByHandle; look at dwVolumeSerialNumber/nFileIndexHigh/nFileIndexLow.
If you're using .NET, the official recommendation from Microsoft is to use StringComparison.OrdinalIgnoreCase for comparison and ToUpperInvariant for normalization (to be later compared using Ordinal comparison). This also applies to Registry keys and values, environment variables etc.
See New Recommendations for Using Strings in Microsoft .NET 2.0 for more details.
Note that while it's reliable on NTFS, it can fail with network shares, for example. See #SteveSteiner's answer and links in his post for solutions.
According to Windows Driver Samples FastFAT and CDFS, it uses RtlUpcaseUnicodeString to convert a string to uppercase. According to a brief look in Ghidra, that uses an internal function named NLS_UPCASE, whose behavior is based on your current system codepage.