Can anybody please let me know how to do the above said conversion
As RegSetValueEx requires const BYTE *lpData for the path
To get Present Directory I Use GetCurrentDirectory() ,where the Output is of the type String
If you already use .NET (C++/CLI) then please also use the managed classes for accessing the registry!
Be aware:
System::String is a managed type!
RegSetValueEx and GetCurrentyDirectory is a native Win32 API!
Please use always C++/CLI:
RegSetValueEx ==> Microsoft::Win32::Registry::SetValue
GetCurrentDirectory ==> System::Environment::CurrentDirectory
If it was not intended to use C++/CLI, then please switch it off in your project settings (General: Common language runtime suppoer: No Common Language Runtime Support"
Related
We previously built aws-sdk-cpp locally and designed a library around it. Now I'm upgrading to use Conan provided aws-sdk-cpp instead of a locally built one, but I'm getting errors from our library.
I call AWS functions such as the following,
std::string src_bucket;
DeleteObject
// ...
obj.WithBucket(src_bucket).WithDelete(std::move(del));
but I get errors like this.
error: no matching function for call to 'Aws::S3::Model::DeleteObjectsRequest::WithBucket(const string&)`.
Has this function call changed to now allow std::string? Is there a way to make AWS methods accept std::string?
Is there a way to make AWS methods accept std::string?
Yes. These functions accept std::string if custom memory management is disabled:
If the compile-time constant is enabled (on), the types resolve to STL types with a custom allocator connected to the AWS memory system.
If the compile-time constant is disabled (off), all Aws::* types resolve to the corresponding default std::* type.
It looks like the former is what you get, and the latter is what you expect - perhaps you've switched from linking the SDK statically (default off) to linking the SDK dynamically (default on)?
In any case, you'll either have to somehow build the SDK with custom memory management disabled, use types like Aws::String yourself, or convert between Aws::String and std::string as needed.
I'm working on conversion of whole libraries of iOS into Delphi.
I can convert all functions, records etc..
But when I'm importing CoreMIDI there are CFStringRef constants declared as:
extern const CFStringRef kMIDIPropertyName;
and many others that I need to import in order to use some of the functions.
I was looking at the internet and I didn't found any straight way how to do it.
Question is - isn't there some way, for example to load the DLL and get list of the parameters and somehow read the value manually?
I don't care about the effort, but I need it working. And it must work under iOS.
Thanks for any tip of suggestion.
You import symbols on iOS by using dlsym. Since dynamic link is not allowed on iOS you do not call dlopen first. Pass
RTLD_DEFAULT as the module handle when you call dlsym. Like this
Symbol := dlsym(RTLD_DEFAULT, SymbolName);
I have an issue that ive been batteling with for a day or so now and im wondering if anyone might be able to help:
Im am trying to use the ActiveMQ-NMS to dequeue messages via COM in a C++ application. I have managed to build the source and override the 'ComVisible' flag in order to export all the types in the assembly via RegAsm (i did receive warnings about this and the 'Atomic' class but i dont think this is the issue i am facing at the moment).
As part of the RegAsm i have generated a .tlb file that i use in a #import in the C++ client. However, i then receive various errors whilst compiling. Things like:
error C2146: syntax error : missing ';' before identifier 'Keys'
error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
Essentially, it looks like things like the ICollectionPtr (and various others) are unavailable. Can anyone help me as to resolving these issues? Essentially im looking to register the .net ActiveMQ-NMS assembly as a COM compliant component and then use it from C++...
Unless there's some other reason to use COM and NMS, why not just use the ActiveMQ-CPP client? Then you can avoid all the complexity of COM. ActiveMQ-CPP is located here:
I'm trying to port a C++.NET (managed extensions) application to C++/CLI. However I'm not very strong with the syntax yet.
What I'm trying to do is to create a wrapper for a C Dll file.
To do this I'm using DllImport but I failed to found documentation on it's use. There are some problems due to changes of the syntax but I couldn't find out why yet.
The C++.NET line looks like this:
[DllImport("my.dll", CharSet = Ansi, CallingConvention = Cdecl, EntryPoint = "#10")]
static MY_STATUS CPPInit(MY_HANDLE *pLmxHandle);
The idea is to pass a reference of MY_HANDLE to the function which initializes it. One problem is that the keywords Ansi and Cdecl are unknown. I expect I need to put some class infront of them but it's a little hard without docs or samples.
The other thing I have is a function which returns a static string:
char *MyFunc();
Can I assume that it can be mapped to String^?
Thanks in advance.
thanks for the comment.
I thought to myself that I need to build a mixedmode library in order to avoid p/invoke. This just takes some time though.
Actually I solved the compile error in another way. Although I havn't tested it yet because I'm facing some 32/64 bit issues which I can't solve because of other bugs in Whidbey beta2.
My solution was to write the protype in the following way:
interior_ptr<MY_HANDLE> pMyHandle;
From what I understood it should give the function a reference (hence an address) to the dll function. Once I get to try it out I will see if my idea works.
Otherwise I will go for the following option (which i've been offered):
[Out] IntPtr p_MyHandle
Anyway I think the problem is solved because one of those should work.
I have a managed DLL (written in C++/CLI) that contains a class used by a C# executable. In the constructor of the class, I need to get access to the full path of the executable referencing the DLL. In the actual app I know I can use the Application object to do this, but how can I do it from a managed DLL?
Assembly.GetCallingAssembly()
or
Assembly.GetExecutingAssembly()
or
Assembly.GetEntryAssembly()
Depending on your need.
Then use Location or CodeBase property (I never remember which one).
#leppie: Thanks - that was the pointer I needed.
For future reference, in C++/CLI this is the actual syntax that works:
String^ appPathString = Assembly::GetEntryAssembly()->Location;
GetExecutingAssembly() provided the name of the DLL
GetCallingAssembly() returned something like System.Windows.Forms
GetEntryAssembly returned the full path, similar to GetModulePath() under Win32.