The long date for culture "en-ca" is MMMM-dd-yy . This is correct and I have verified this with documentation. You can verify the result in .NET by doing the following.
Dim culture As CultureInfo = CultureInfo.GetCultureInfo("en-ca")
MsgBox(culture.DateTimeFormat.LongDatePattern)
I am trying to figure out why there is a difference with the NLS API which will return "MMMMM d, yyyy"as the default long date. This is incorrect. Am I missing something here? I'm just curious if anyone knows the specifics around this.
NLS API Reference:
http://msdn.microsoft.com/en-us/goglobal/bb896001.aspx
This has changed between .NET 3.5SP1 and .NET 4.0. .NET 3.5 produces MMMM d,yyyy, same as the documented Vista NLS value.
.NET 4.0 produces MMMM-dd-yy. Same as what I get when I use GetLocaleInfo() on Win7 with:
wchar_t buf[256];
GetLocaleInfo(0x1009, LOCALE_SLONGDATE, buf, 256);
I think .NET 4.0 is now using the Windows locale info instead of relying on its own tables. Nevertheless, nothing changes as fast as culture data. If you think this is incorrect then you can submit feedback at connect.microsoft.com
Related
If I have a .NET Standard 2.0 library project that is being consumed by a .NET 6.0 console project, are there any performance benefits if I also instruct the compiler to produce a .NET 6.0 version of the library?
I don't plan to use any functionality available on .NET 6.0, I just want to know if the .NET 6.0 version receives extra-love from the compiler.
Asked the same thing on Twitter, and was fortunate enough to receive feedback from reputed experts Bartosz Adamczewski, Immo Landwerth, Jared Parsons and Lucas Trzesniewski
Here is the question link.
Here are the most relevant bits of info you can extract from the original Twitter thread:
What you might gain is better IL, so things like strings and certain
other things are handled better by the front-end compiler C# and
better IL is generated, this, in turn, could provide better codegen in
JIT - Bartosz Adamczewski
#jaredpar can correct me but for the most part the code gen isn’t
depending on the target framework, except for cases where the code gen
users specific APIs, which is rare. - Immo Landwerth
That is correct. At the compiler level there is no concept of target
frameworks, there are just references. Hence all decisions about code
gen are based on the API in the references. - Jared Parsons
In the case of .NET 6, you'll get access to some new APIs such as
DefaultInterpolatedStringHandler, so for instance all of your string
interpolation expressions ($"...") will get a perf boost just by
targeting net6.0. Also, there are new method overloads such as
StringBuilder.Append that take string interpolation handlers as
parameters. Your string interpolation expressions will target these
instead when targeting net6.0, and your code will allocate less than
on other targets. So yes, in some cases, your code will get more
love by the compiler if you add a net6.0 target 🙂 - Lucas
Trzesniewski
I've read here that Microsoft is deprecating WMI. I need to start a project in .NET Core and query information from Windows, e.g. Win32_OperatingSystem or Win32_LogicalDisk.
I'v read that you should avoid Get-WmiObject in PowerShell and use Get-CimInstance instead. What (which Nuget/library) should be used in .Net Core now to query those kind of information?
You can use the Windows Compatibility Pack (article, nuget) for .NET Core which gives you access to a lot of Windows-only APIs but restricts your app to running only on Windows, probably not something you're worried about. This compatibility pack is also known as platform extensions. With this you would need to learn how to use the classes in the System.Management namespace (API Ref, example code 1, example code 2). Keep exploring the API for examples.
Additionally, it looks like there is a newer cross-platform open-source system similar to CIM made by Microsoft. Though apparently not everything available in WMI is available with this, so your mileage will vary: https://www.nuget.org/packages/Microsoft.Management/ and https://www.nuget.org/packages/Microsoft.Management.Infrastructure/
Hope this helps.
I am using interop and within a console application launching CAD as per the following example. How can I find the programID of AutoCAD which is installed on my local machine.
For example in the below article it uses
const string progID = "AutoCAD.Application.17.1";
https://through-the-interface.typepad.com/through_the_interface/2007/12/launching-autoc.html
Try just using "AutoCAD.Application" with no specific reference. Works for me.
Your issue is going to be the reference to the proper version of AutoCAD though. I get around this by using late binding.
Pretty good information on Late Binding
Not really sure that this is kept up to date -->
AutoCAD Version List
I'm using Delphi XE2 on Win7 x64, compiling for Win32.
I've started using CSIDL_LOCAL_APPDATA to design installations for my first software release.
I see on MSDN that as of Vista, MS wants us to start using KNOWNFOLDERID values instead of CSIDL values:
However, when I try to replace GetSpecialFolderPath(CSIDL_LOCAL_APPDATA,false) with GetSpecialFolderPath(FOLDERID_LocalAppData,false), XE2 won't recognize FOLDERID_LocalAppData.
I would think that since XE2 came out long after Vista, that there should (if you'll forgive me) be support/recognition of these constants (?) in Winapi.Windows in XE2.
If not, does anyone know if Win10 still recognizes CSIDL values?
Not everything in the Win32 API that Delphi natively supports is implemented in the Winapi.Windows unit. For instance, CSIDL support is implemented in the Winapi.SHFolder unit, and KNOWNFOLDERID support (which yes, does exist in XE2) is implemented in the Winapi.KnownFolders unit.
GetSpecialFolderPath() is not a native Delphi function, so you must be using third-party code. CSIDL is an Integer that is passed to SHGetFolderPath() (or older CSIDL-based functions), whereas KNOWNFOLDERID is a TGuid that is passed to SHGetKnownFolderPath() instead. So you can't just pass a FOLDERID_... constant to GetSpecialFolderPath() unless it has been overloaded to accept either a CSIDL or KNOWNFOLDERID as input.
I'm using C++ Builder 2009.
I'm looking for a way to get the system's date time format, so that I can use that in displaying dates and times using the system's native format. E.g. If the user's format is English (US) then the display for a day can be "mm/dd/yyyy".
I would prefer a solution that works for both XP and 7. However I'll be happy with an answer that works with just Windows 7. Thanks!
If you use TDateTime, you can use the DateTimeToStr() function which uses the system defaults, unless overridden, to format the string.
Update: To get the string, use ShortDateFormat or LongDateFormat
ShortDateFormat gives me access to what I need.