Using Windows Forms and VC++ with Unmanaged Static Libraries - winforms

I am currently trying to write a UI for a Data Acquistion System in Visual Studio C++ 2010, and I am having a lot of trouble dealing with the interfacing of the third party libraries I am using and Windows Forms. The two libraries I am using are DAQX, a C library for a Data Acqustion System, and VITCam, a C++ library for a 1394 High Speed Camera. It's extremely frustrating trying to work with these libraries and any UI library that VS has to offer, as none of the function arguments ever get along.
DAQX uses windows types like WORD and DWORD, in normal C fashion, and when I'm writing a normal program, no UI involved, it works fine, but Windows Forms seems to hate anytime I want to make a simple DWORD Array inside the class.
VITCam is even worse. I can open the camera fine, but I am completely lost when it comes to trying to put the image on the screen somehow. I haven't uncovered an equivalanet, easy to follow way for putting it to the screen as to how the documentation puts it:
CDC* pDC=GetDC(); // obtain the device context for your window...
// move the image data
::SetDIBitsToDevice(pDC->m_hDC,0,0,
(int) (MyCam.GetDispBuf()->bmiHeader.biWidth),
(int) (MyCam.GetDispBuf()->bmiHeader.biHeight),
0,0,0,(WORD) (WORD) MyCam.GetDispBuf()->bmiHeader.biHeight,
MyCam.GetDispPixels(),MyCam.GetDispBuf(),
DIB_RGB_COLORS);
I can barely follow it as is. So, without doing to much blathering, How do most people work with static unmanaged libraries that were not developed with Windows Forms in mind? I've tried MFC as the VITCam documentations mentioned it, but it makes very little sense and isn't as intuitive as Windows Forms feels.
Edit:
This is the error message I get when trying to use a normal (at least to me) array.
Error 1 error C4368: cannot define 'buffer' as a member of managed 'WirelessHeadImpact::Form1': mixed types are not supported
And it points to this line:
private:
WORD buffer[BUFFSIZE*CHANCOUNT];
What I had before was this:
static array<WORD>^ _buffer;
And within a function I create the former array, pass it to the function, then return the latter after looping through and updating the array.
WORD buffer[BUFFSIZE*CHANCOUNT];
DWORD scansCollected = 0;
while (total_scans < SCANS) {
daqAdcTransferBufData(_handle, buffer, BUFFSIZE, DabtmWait, &scansCollected);
if (scansCollected > 0) {
for (WORD i=0;i<scansCollected;i++) {
_buffer[i] = buffer[i];
}

mixed type support is removed in Visual C++ 2005. If you want to associate a DWORD array to a managed class, use new (not gcnew) to allocate the array itself on the native heap and save the pointer of the array in the class.
by the way, you cannot pass addresses of objects on the managed heap to a native function without pinning the object, otherwise the GC is free to move the object at any time. If you want to pass a managed value to a native function, make sure your pass by value or the object is pinned.
It helps the readers if you post the actual error message you are getting, instead of having to guess out from your question.

Related

How to create FMU slave and initialise FMU in C using Modelica's fmi headers

I'm creating a simple FMI demo system to try out FMI where I have 1 simulator connected to an FMU which computes the state of the system (represented as a number calculated from a closed-form equation) and another FMU that controls the system via a parameter in the closed-form equation. So the system looks something like
FMU-system <--> Simulator <--> FMU-control
In every iteration, I'm updating the system state based on 1 equation, and passing it to the control, which returns a parameter to be passed to the system.
I'm using FMI 2.0.3, and have read the specification. Right now I have 3 files, 1 to act as a simulator and 2 to act as the FMUs. But I'm having difficulties with the implementation of the FMUs and the initialisation of the simulator.
To initialise the FMU, my understanding is I need to call fmi2Instantiate which has this signature.
fmi2Component fmi2Instantiate(fmi2String instanceName, fmi2Type fmuType, fmi2String fmuGUID, fmi2String fmuResourceLocation, const fmi2CallbackFunctions* functions, fmi2Boolean visible, fmi2Boolean loggingOn);
But I don't know what to pass in the function for the GUID, resource location and callback function. How should I implement the callback function and initialisation?
Then to implement the FMU, my understanding is I need to implement fmi2SetReal, fmi2GetReal and fmi2DoStep, but I can't figure out how to implement them in terms of code. These are the signatures
fmi2Status setReal(fmi2Component c, fmi2ValueReference vr[], size_t nvr, fmi2Real value[])
fmi2Status getReal(fmi2Component c, fmi2ValueReference vr[], size_t nvr, fmi2Real value[])
fmi2Status doStep(fmi2Component c, fmi2Real currentCommunicationPoint, fmi2Real communicationStepSize, fmi2Boolean noSetFMUStatePriorToCurrentPoint)
But I can't figure out how to implement these functions. Is fmi2Component c meaningless here? And I suppose I have to do the system state computation for the FMU-system in doStep. How should I update the state and pass the code here?
Sorry if this is too many questions but I was trying to look for a tutorial too and I couldn't find any.
https://github.com/traversaro/awesome-fmi
This is a curated list of Functional Mock-up Interface (FMI) libraries, tools and resources.
There are non commercial tools available. Check them out, you will get idea to implement these functions for your application.
A good starting point to implement FMI support are the open source Reference FMUs (which recently also got a simple FMU simulator) and fmpy:
https://github.com/CATIA-Systems/FMPy
https://github.com/modelica/Reference-FMUs/tree/main/fmusim

How to design generic backward compatible API for embedded software application library interface in C?

I am tasked to assist with the design of a dynamic library (exposed with a C interface) aimed to be used in embed software application on various embed platform (Android,Windows,Linux).
Main requirements are speed , and decoupling.
For the decoupling part : one of our requirement is to be able to facilitate integration and so permit backward compatibility and resilience.
My library have some entry points that should be called by the integrating software (like an initialize constructor to provide options as where to log, how to behave etc...) and could also call some callback in the application (an event to inform when task is finished).
So I have come with several propositions but as each of one not seems great I am searching advice on a better or standard ways to achieve decoupling an d backward compatibility than this 3 ways that I have come up :
First an option that I could think of is to have a generic interface call for my exposed entry points for example with a hashmap of key/values for the parameters of my functions so in pseudo code it gives something like :
myLib.Initialize(Key_Value_Option_Array_Here);
Another option is to provide a generic function to provide all the options to the library :
myLib.SetOption(Key_Of_Option, Value_OfOption);
myLib.SetCallBack(Key_Of_Callbak, FunctionPointer);
When presenting my option my collegue asked me why not use a google protobuf argument as interface between the library and the embed software : but it seems weird to me, as their will be a performance hit on each call for serialization and deserialization.
Are there any more efficient or standard way that you coud think of?
You could have a struct for optional arguments:
typedef struct {
uint8_t optArg1;
float optArg2;
} MyLib_InitOptArgs_T;
void MyLib_Init(int16_t arg1, uint32_t arg2, MyLib_InitOptArgs_T const * optionalArgs);
Then you could use compound literals on function call:
MyLib_Init(1, 2, &(MyLib_InitOptArgs_T){ .optArg2=1.2f });
All non-specified values would have zero-ish value (0, NULL, NaN), and would be considered unused. Similarly, when passing NULL for struct pointer, all optional arguments would be considered unused.
Downside with this method is that if you expect to have many new arguments in the future, structure could grow too big. But whether that is an issue, depends on what your limits are.
Another option is to simply have multiple smaller initialization functions for initializating different subsystems. This could be combined with the optional arguments system above.

Ansi C dynamic include

I was assigned to edit part of Ansi C application but my knowledge of pure C is just basics. Anyway current situation is I have map1_data1.h, map1_data2.h, map2_data1.h, map2_data2.h and variables in those files are always connected to the map name = map1_structure in map1_data1.h and so on.
In app there is #include for each file and in code then something like
if (game->map == 1){
mapStructure = map1_structure
} else {
mapStructure = map2_structure
}
I have to extend this to be able to load the map dynamicly so something like
void loadMap(int mapId){
mapStructure = map*mapId*_structure // just short for what i want to achieve
}
My first idea to do so was removing map name connection in variables name in map1_data.h and have just structure variable in there. That requires only one header file at time to be loaded and thats where I'm stucked. Havent found any clues to do so on google.
I would like to have it as variable as possible so something like #include "map*mapId*_data1.h" but should be ok to have 1 switch in one place in whole app to decide on what map to be loaded.
One more thing, the app keeps running for more than 1 game = it will load various maps in one run.
Judging from the comments, you have a single type, call it Map, which is a structure type containing a collection of different data types, including 3D arrays and points and so on. You need to have some maps built into the program; later on, you will need to load new maps at runtime.
You have two main options for the runtime loading the maps:
Map in shared object (shared library, dynamically loaded library, aka DLL).
Map in data file.
Of these two, you will choose the data file over the shared object because it is, ultimately, simpler and more flexible.
Shared Object
With option 1, only someone who can compile a shared library can create the new maps. You'd have a 'library' consisting of one or more data objects, which can be looked up by name. On most Unix-like systems, you'd end up using dlopen() to load the library, and then dlsym() to find the symbol name in that library (specifying the name via a string). If it is present in the library, dlsym() will return you a pointer.
In outline:
typedef void *SO_Handle;
const char *path_to_library = "/usr/local/lib/your_game/libmap32.so";
const char *symbol_name = "map32_structure";
SO_Handle lib = dlopen(path_to_library, RTLD_NOW);
if (lib == 0)
...bail out...
map_structure = dlsym(lib, symbol_name);
if (map_structure == 0)
...bail out...
You have to have some way of generating the library name based on where the software is installed and where extensions are downloaded. You also have to have some way of knowing the name of the symbol to look for. The simplest system is to use a single fixed name (map_structure), but you are not constrained to do that.
After this, you have your general map_structure read for use. You can invent endless variations on the theme.
Data file
This is the more likely way you'll do it. You arrange to serialize the map structure into a disk file that can be read by your program. This will contain a convenient representation of the data. You should consider the TLV (type-length-value) encoding scheme, so that you can tell by looking at the type what sort of data follows, and the length tells you how many of them, and the value is the data. You can do this with binary data or with text data. It is easier to debug text data because you can look at and see what's going on. The chances are that the difference in performance between binary and text is small enough (swamped by the I/O time) that using text is the correct way to go.
With a text description of the map, you'd have information to identify the file as being a map file for your game (perhaps with a map format version number). Then you'd have sections describing each of the main elements in the Map structure. You'd allocate the Map (malloc() et al), and then load the data from the file into the structure.

embedded software structure for sublevel screens and menus

I'm new into embedded c programming and I need some advice.
I'm trying to create a menu structure with underneath screens on an embedded system, the OS code and the drawing/menu libraries are ready, but I can't figure out how I'd design this system.
it'll have :
menus and submenus
password screens that user can authenticate before entering some menu items
and the screens beneath them.
I wrote some code that's working and still feels like I'm writing procedural spagetti code. And I'm new to embedded c systems so I don't know if I can use classes or objects inside the code. I'd be grateful if someone shows me the right way to do this. I'm experienced about programming anything else BTW so feel free with the tech talk. ;)
BTW the menu code is structured like this:
menu myMenu;
entry* myMenuEntries;
int selection = 0;
myMenuEntries[0] = [entry definer code];
...
myMenu.entries = (entry *) myMenuEntries;
selection = DisplayMenu(myMenu);
switch(selection){
case 0: exit(); break;
}
How can I create an object in embedded c like it's used in myMenu.entries?
I would definitely use object oriented C here, like you suspect is possible. There are lots of references to how to do oop in C on stack overflow. You make classes out of structs and use function pointers as the member functions which can then be overridden if you want polymorphism.
Each screen could have on onEnter(), for example, to initialize stuff when the screen is loaded, and you could have a drawable class that can encompass strings, primitives, images, etc that know how to draw themselves at any x,y coordinate. You could also have a standard screen object which is made up of a list of the objects on the screen, their coordinates, and contents. These could be initialized at compile time, too, in a big table.
(I've done all this on a DSP using C and ASM)
There are also ready made libraries that can do this. I know that micrium has one. I'm on my phone or I'd Google it and put the link here.

Passing array of bytes to an ActiveX

I want to pass a array of bytes to ActiveX. I am using delphi 7 and i'm using a InProcess Server (DLL).
I am using a pointer to the array of bytes and the size of the array, passing it to the InProcess Server. It is working well. I did this because I need performance. Does anyone see any trouble in this approach?
I see a post that is very similar: What data type is suitable to handle binary data in ActiveX method? but nobody gave this answer.
Passing the byte array as pointer together with size information is just fine.
However, some programming languages support only a small subset of all possible types. For example, Visual Basic for Application (not VB.NET) can only handle Automation compatible data types (see http://msdn.microsoft.com/en-us/library/cc237562(v=prot.20).aspx), and even not all of them (no support for 16bit unsigned integers, for example). To be on the safe side, I always use SAFEARRAYs whenever there is no good argument against it.
Also note that using non-automation compatible interfaces forces you to provide your own marshalling code in case you wanted to use your component OutProc. Since you mention that you intend to use your component only InProc, this should not worry you.
Regards,
Stuart

Resources