I am wondering if anyone can help me. I am trying to add an SQLite database to an Gtk# application using monodevelop. I want to reference a different library depending on what version of OS is is used. I am unsure how to detect if it is linux or not or if this is possible.
#if (linux)
using SqliteConnection = Mono.Data.Sqlite.SqliteCommand;
using SqlCommand = Mono.Data.Sqlite.SqliteCommand;
#else
using SqliteConnection = System.Data.SQLite.SQLiteConnection;
using SqliteCommand = System.Data.SQLite.SQLiteCommand;
#endif
Related
I have 3 versions of Matlab installed on my PC. I want to call some Matlab command from my vb.net program. So I created a Matlab object in vb.net and calls the commands. But I want to executes these commands with a specific version of matlab, let's say 2013b, using matlab command window.
How do I do it?
So I'm writing a small tool to do Voice Recognition. I started just with SAPI 5.4 and used an SRGS xml file to set up my grammar. It worked very nicely. All my commands were recognized easily. However, I'm trying to get this thing to run on XP and I'm having trouble. I've used the following code to read in my existing xml file:
listener = New SpSharedRecoContext()
AddHandler listener.Recognition, AddressOf Handle_Speech
Dim grammar As ISpeechRecoGrammar
grammar = listener.CreateGrammar()
grammar.CmdLoadFromFile(Utilities.INI.ConfigPath & "\Voice_Commands.xml")
grammar.CmdSetRuleIdState(0, SpeechRuleState.SGDSActive)
However, the performance of SAPI 5.1 in recognizing commands is much-much worse than 5.4. First of all it starts an external listener app that you have to turn on (I guess this isn't too bad). But I think the main problem is that the listener will start doing OS operations when I speak (opening folders etc.); so its obviously listening for more than just my pre-defined set of commands.
Does anyone know how to make SAPI 5.1 perform like 5.4?
Thanks,
Ian
Are you sure this is XP? The behavior you're describing sounds like you're getting Windows Speech Recognition running, which only runs on Vista and above.
You need an in-proc recognizer (SpInProcRecoContext), instead of the shared recognizer. This needs a bit of work to initialize (you need to attach an engine & audio source). I wrote a bit on this on my blog, but I used the native APIs to do it.
Lastly, the SR engine on XP is indeed not as good as the SR engine in Vista and above. After all, the XP SR engine is over a decade old.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to detect Windows 64 bit platform with .net?
I am totally new to VB. I have VS2008 express edition on my machine and I want to know the bit architecture of my (target user's) machine. I got OS name and major and minor versions but how do I get bit architeture?
I have already linked to a previously asked question on this but
The easiest solution is (if you can) is use Visual Studio 2010 onwards, then If you want to know what the bitedness is of the operating system you can simply use:
Environment.Is64BitOperatingSystem
If you want to know the bitedness of the processor then use kor_'s answer already given (although why you would need to know this I don't know)
Note:- you can also check the bitedness of the process you are running:
Environment.Is64BitProcess
Dim Is64Bit As Boolean
Is64Bit = Not String.IsNullOrEmpty(Environment.GetEnvironmentVariable("PROCESSOR_ARCHITEW6432"))
See also: How to detect Windows 64-bit platform with .NET?
If you want to know whether the OS is 32-bit or 64-bit and you're using .NET Framework 4.0 or higher, use Environment.Is64BitOperatingSystem.
If you want to know whether the current process is 32-bit or 64-bit and you're using .NET Framework 4.0 or higher, use Environment.Is64BitProcess.
I've tested these two on Windows 7 and XP SP3, but not on any earlier OS version.
If you want to know the CPU bitness, you can use this WMI call:
Dim mo = New ManagementObject("Win32_Processor.DeviceID='CPU0'")
Dim i As UShort = CUShort(mo("Architecture"))
Select Case i
Case 0
Return "32 Bit"
Case 6 'Itanium
Return "64-bit"
Case 9
Return "64-bit"
Case Else 'Ooops!
Exit Select
End Select
I have this monstrous C++ application built using MFC(mainly) and COM. It links to several libraries and does a lot of scientific computing. So, now I want to add some new features to it and as an organizational policy, we are developing everything new using .NET. So, this new UI feature is going to be built using WPF and will be consumed in this existing C++ application.
I know how to use a WPF control in a C++ application, so that's not the problem. The problem is that when I try to turn on CLR on this project, it takes a lot of time (around 10 minutes) in linking stage to perform the linking and produce a mixed mode executable. In the end, it manages to do so and successfully creates the executable. But the problem is that whenever I launch this executable, it crashes. I tried to debug InitInstance but it crashes somewhere before this. I am a little stumped on what to try next.
Does anybody have any idea what might be the cause of this.
The target framework of the mixed mode assembly is 4.0 (as it should be) so THIS is not the problem here.
FYI, ILDasm fails to load this exe as well. It takes a lot of time, gives no error but it doesn't load it either. This gives me the impression that somehow managed image is not created properly.
Not sure if this is necessary, but it doesn't hurt either. New MFC projects have this in the constructor of your CWinApp-derived class:
#ifdef _MANAGED
// If the application is built using Common Language Runtime support (/clr):
// 1) This additional setting is needed for Restart Manager support to work properly.
// 2) In your project, you must add a reference to System.Windows.Forms in order to build.
System::Windows::Forms::Application::SetUnhandledExceptionMode(System::Windows::Forms::UnhandledExceptionMode::ThrowException);
#endif
If I have an application that is written in .net Compact Framework (and runs on Windows CE) and is theoretically compatible with Windows Embedded Standard O/S, would it still be compatible if it makes use of OpenNETCF functionality?
Things like running .exe files with help of OpenNETCF for example. I am assuming that OpenNETCF uses P/Invoke under the hood, which might make the application incompatible with other OS than Windows CE.
I don't use P/Invoke in my code, but I can't asnwer for sure whether OpenNETCF does or does not.
.net compact framework 2.0 and windows embedded standard
OpenNETCF does use P/Invoke extensively.
It is effectively a wrapper for some core OS functionality in Windows CE and its derivatives, that is not otherwise implemented in the Compact Framework. In practice this means extensive P/Invoking of coredll.dll; the basic OS module for Windows CE.
Windows Embedded Standard is Windows XP. For this reason I would not expect you to be able to use OpenNETCF.
Depending on the version you're using you may be able to get hold of the OpenNETCF code here (or buy the latest of course), and see what's going on under the hood. Also, what you may find is that the calls you are making to the OpenNETCF are actually implemented anyway when compiling for Windows Embedded Standard.
One way to approach this is to make another project to target this platform, containing exactly the same code files, but no reference to the OpenNETCF, then work through fixing the compile errors.
You can add a Conditional compilation symbol to either the CE project or the Windows Embedded project then fix the errors like so (This example is not for OpenNETCF, but you get the idea):
public static string ExecutingAssembly
{
get
{
#if WindowsCE
return Assembly.GetExecutingAssembly().GetName().CodeBase;
#else
return Assembly.GetExecutingAssembly().Location;
#endif
}
}
Obviously you will then have to create a build for each platform as the outputted assemblies will now be different.
As Chris points out, the SDF makes heavy use of coredll P/Invokes. That's not to say everything does, but it's certainly a minefield. I tend to have a CF project and a FFX project and places where I have overlap I use aliasing, like this:
#if WindowsCE
using Thread = OpenNETCF.Threading.Thread2;
#else
using Thread = System.Threading.Thread;
#endif
Then in the code you just do your normal
var thread = new Thread(...);
And things work out.
Now ages ago we did start an interesting side project of creating a coredll "shim" for the desktop. What that means is that a p/invoke to "coredll" on the desktop would actually call that DLL, which would in turn marshal the calls off to kernel32, user32 or whatever. Our testing for what we implemented (and there's a fair bit there) showed that it worked just fine, so if you're using a limited subset of APIs, just dropping it on the PC might make the CF assembly "just work".