Long story, long:
I am adding a web interface (ASPX.NET: VB) to a data acquisition system developed with LabVIEW which outputs raw data files. These raw data files are the binary representation of a LabVIEW cluster (essentially a structure). LabVIEW provides functions to instantiate a class or structure or call a method defined in a .NET DLL file.
I plan to create a DLL file containing a structure definition and a class with methods to transfer the structure. When the webpage requests data, it would call a LabVIEW executable with a filename parameter. The LabVIEW code would instantiate the structure, populate the structure from the data file, then call the method to transfer the data back to the website.
Long story, short: How do you recommend I transfer (copy) an instance of a structure from one .NET program to the VB.NET program that executed it?
Ideas considered: sockets, temp file, xml file, console output, config file, web services, CSV, some type of serialization, shared memory
Serialized XML would be my first initial stab at it. (System.Xml.Serialization namespace).
It's Microsoft-specific but it's standard "enough" that you could probably get another program w/ another technology to read it with minimal finagling, compared to previous MS object serialization technologies I've heard horror stories about.
I would build the LabVIEW code (file->(XML)-string) into a DLL which you can call directly and would return the serialized string.
Or you could read the datafile 'as-is', the LabVIEW structs aren't that hard. and they are pretty good documented:
How LabVIEW stores data in memory
Flattened data
Related
I have to port an old VB6 program to VB.NET and stumbled across an old ".res" (Resource) file, which is stored in binary format. Using VS 2013, I can embed that file into my .NET project, and VS shows me that it contains simply a string table.
The problem is, I cannnot figure out how to bring those res file into a more modern text format, or how to load the strings directly from the res file. I linked file to my application es an embedded resource, but all my atttempts to use VB6.LoadResString from the "Visual Basic Compatibility library" lead to an exception, showing the key was not found.
Furthermore, it seems VS does not allow me to copy/paste the string table into a text file, at least, not at a whole. Actually, it allows me to copy/paste one string after another, but as you can imagine, that is extremely cumbersome and error-prone. That is why I am looking for a better solution. Any ideas?
There is a functional VB6 Class for doing this at:
ResDecomp Class Decompiles RES Files
Sample programs are included, one of them a sort of "viewer" and the other just extracts RT_STRING resource strings to an XML document. You could easily change the latter to dump the string values to a text file, database, etc. instead.
Embed the .res file to a simple VB6 program which loops from min to the max ID and write out the strings to a text file using LoadResString (error trap for missing IDs).
Is there any software to get BVH data directly from kinect? I searched on net and found Kinect BVH MoCap(http://tech.integrate.biz/kinect_mocap.htm) , but it is not working for me.
No. There is no built in mechanism to save Kinect data at all - no matter what format you want it in. The Kinect Studio does save off stream data, but I've not looked at the files to see what they look like internally.
You could look into the Kinect Toolbox, which provides functions to save off any of the 3 streams to a file. You can save the file and then manipulate it as necessary, perhaps write a parser to translate the data. Alternatively, you could manipulate the data before you save it off.
You could also write your own parser. The Skeleton objects are serializable, which means you could save them to a List (or some other array type object) along with a time stamp. When you are ready to save to the file, serialize the List and you will get a standard XML dump of the List and the Skeleton objects inside. Again, you could write a function that just translate it into the proper format before saving it as well.
I've seen some small examples posted by Shawn Hargreaves showing manually defining some xml content with the intent to create and populate instances of c# classes, which get loaded through the content pipeline.
I can see that this would be useful if you had an editor capable of writing the file, allowing you to load a level or whatever.
But, I'm curious... does it only do read operations? Can you use this concept to save game data?
What else might it be used for?
Automatic XNB Serialization (details) is simply the ability for the content pipeline to read/write data without needing a ContentTypeWriter or ContentTypeReader. It doesn't actually provide any new features, besides reducing the amount of code you have to write to use the content pipeline.
Loading from XML (using IntermediateSerializer or through the content pipeline using the XML importer) is a separate thing.
IntermediateSerializer automatically converts .NET object instances to/from XML using reflection.
The content pipeline (whether you are using automatic XNB serialization or not) converts .NET object instances to/from binary XNB files.
The content pipeline also provides an extensible importer/processor system, on the content-build side, for generating the .NET objects in the first place (and it includes various built-in importers/processors). The built-in XML importer just uses IntermediateSerializer to go from XML to a .NET object instance.
The reason why you can't use these in your game to perform write operation (eg: saving the game state, a built-in level editor, etc) is that IntermediateSerializer (both read and write) and the writing-XNB half of the content pipeline require XNA Game Studio to be installed.
XNA Game Studio is not a redistributable. (Only the XNA runtime is redistributable.)
Apologies if this is a duplicate, but I've not managed to find this question being asked directly.
The general opinion here (that's me and him across from me) is that they shouldn't, the reason being that DLLs can be shared; therefore the idea of having application-specific information in a DLL is nonsense. If the information is not application-specific, then constants can be used.
A further question is, assuming that DLLs do not have their own config file, whether DLLs should use the configuration files of the executable that loaded the DLL, or instead be passed the relevant data as part of some kind of constructor. Our opinion here is the latter, as it makes it more testable, the downside being that it will sometimes be necessary to pass a significant amount of data to the dll.
Opinions?
There's no reason why you can't have the best of both worlds in terms of "simple to configure with config files" and "testable". Have a static method which can create instances from the configuration file, but also provide a constructor for more control and testability. The static method would just grab the settings and call the constructor.
I believe it's possible to create settings classes for DLLs just like any other project, and then you just need to put the actual text into the application's config file instead of one for the DLL. Basically ignore the app.config generated for the library project, except to use as a template for the application's central one.
Alternatively, use something like Spring.NET to manage this sort of thing :)
Usually, I guess you should pass relevant information to the functions you're calling or set relevant properties in objects you're creating that are defined within the DLL. I guess that's why .NET does not really support config files for DLLs (you can create them, but they'll not be used when running).
I have one scenario, where DLLs are reading a config file, but that is very special: The .NET DLL exports objects as COM objects for use by Microsoft Navision. It communicates with a factoring bank using an XML-RPC interface.
While the DLL is installed on every user's machine, the configuration for the interface is common to all users, so I have a configuration placed on a network drive that's mapped on every PC and the configuration (URL, credentials, etc.) is read from that common file.
Whether that's good practice is up to the reader, but in that scenario having a common config file just made sense...
I've been tasked with maintaining an application originally written in VB6. It has since been imported into VB .Net and to say the least the code is anything but Object Oriented. The code is riddled with classes which contain nothing more than Public Shared attributes(variables) and methods(functions), the result of which restricts the application from opening more than one project at a time.
A project consists of a XML file which contains general project settings, as well as the location to an Access database which contains other project related data. Over the years the format of the XML file has been modified, and an update and versioning strategy has been adopted. The chosen strategy performs an update upon open whenever an old version is encountered. Thus far, updates have only consisted of rearranging data within the XML file or making database schema changes and moving data from the XML file to the database.
Having quite a bit of background in OOP it's easy for me to see that a project should be a self contained object which other objects interact with. However, I fail to see how to apply the chosen update strategy in OOP.
The problem of implementing the chosen update strategy in OOP has kept me from using OOP as of yet. If anyone has experience with such a task, or recommendations on how to proceeded I'd appreciate any assistance you can provide.
Build a class which reads the XML file in, and provides properties/methods/etc based upon the data in that file. When the class writes the XML file back out, have it format in the manner needed for the new version.
So, basically, the class will be able to read in the current version, plus all the older versions, but it will always write out the new version.
Data would be held in internal variables of the class, rather than having to scan the XML file every time you need something.
Adding a VERSION node to your XML file will also help in this case.
You might have answered your own question when you used the word strategy (i.e. the Strategy Design Pattern).
Possibly you could:
Create a project class that knows nothing about conversions but accepts a strategy object.
Create a hierarchy of classes to model each possible conversion strategy.
Use a factory method to build your project object with the right strategy
I don't understand why this is a troubling problem. It could be solved in any number of ways.
If you want to do a full object oriented enterprisey type thing, you could take any subset of the following solution:
Create an interface IProject which
describes how other objects interact
with a project.
Create the current implementation of
Project which implements IProject
and can read and write to the
current version.
Extend Project for each past
version, overriding the xml and
database read methods and having the
constructor call write when these
classes are instanced
For extra enterpriseyness, create a
ProjectFactory, which detects the
version of the file and instanciates
the correct version.
If further versions are needed,
rewrite the current Project to do
the same thing as past projects,
accessing the new version of Project
with all the reads and then calling
write.
The advantage of this solution is that you can continue meandering about with different versions and each new version only requires the ability to be updated to from the previous version, with all previous versions cascading up to the second to last version.