I'm working on a project that was created by a coworker, having been built on LabView on Windows. He used a bunch of DAQmx modules, but I'm having trouble opening them on my Mac.
I realize that DAQmx on the Mac is basically replaced with DAQmxBase - my question is if there's a simple way to switch from one to the other? Or would I need to go through and manually change each instance?
If it's the latter, is there any way to maintain consistency as we collaborate on the program?
To switch between the two APIs, you can use a Conditional Disable Structure and use the OS symbol to change which API is used on each platform.
Note that NI-DAQmx Base is a subset of NI-DAQmx. There's a high likelihood that your colleague has chosen to use capabilities that aren't available on the Mac.
I'm afraid you have to manually change each VI.
There is a conversion utility only to go from DAQmxBase to DAQmx (but probably I would do it manually even in this case).
Related
I'm trying to find a good GUI library I could use to create a program on the computer that connects to a microcontroller by USB. I've never done any GUI work before but I have done a lot of webpage design/tools. We are going to program the microcontroller with C but I don't think the GUI will need to be C. It needs to work on Windows, so probably compile on Windows too. I've also never done any USB transmission but I'm hoping to take it one step at a time.
Right now I'm looking at using GTK but it needs a bunch of other things to download with it. I'm also going to look at QT and someone else suggested making a Windows Forms Application. There's a lot of options out there so I'm having trouble figuring it out.
As for my requirement, it just needs to be a very simple GUI that has a few control buttons, a display area (info from microcontroller), a notification area (basically error messages go here), and maybe a graph. I've included a prototype GUI help give you an idea of what I'm doing.
Edit: It needs to run and compile on Windows. We don't really have a budget for it, free open source is preferred. I don't need something elaborate and fancy, I just want to get it done as fast as possible.
We are using a TTL-232R cable, UART interface. I know nothing about USB transmission, school has crushed me.
From what you've specified, I would set base-camp up at Java.
Java in Eclipse to write the code.
Java Swing libraries (helped by the WindowBuilder plugin for Eclipse) to "draw" the GUI. It is very easy to create "Windowsy" GUIs using these.
JFreeGraph libaries to allow you to create graphs very easily, again from within Eclipse.
RXTX library for "virtual COM port" serial communication within Java (it doesn't sound like you're using proper USB, but just RS232 with a USB adapter).
Your created GUI would run on any machine with Java installed, which is not a big ask for the end user. You can even create a Windows executable/installer from the resulting Java files if you wanted it to be a (apparently) native Windows application.
And - bonus - all the tools mentioned are free as a bird.
It will kind of depend on what kind of compiler, IDE, etc you will settle on. If you are going to windows cold, and
money is an issue, then open source is always a good thing to look at. I have enjoyed using eclipse and Code::Blocks IDEs. For C/C++, I use minGW. In terms of GUI plug-ins, HERE are some conversation with GUI recommendations specifically for use with Code::Blocks.
If money is not an issue, I have use National Instruments LabWindows/CVI full dev kit forever. It is one of the easiest ANSI C compilers/IDE I have ever used. It is only ANSI C, but has extensions to make using instrumentation easy. I have written a little USB stuff (not much), sockets, instrumentation, and many GUI apps.
Please comment what tools you currently prefer, I may have other suggestions.
Lazarus CodeTyphon has cross platform native compiler with GUI working on every supported platform. It supports 8 OS-CPU host layers (Win32, Win64, Linux32, Linux64, FreeBSD32, FreeBSD64, Solaris32 and Solaris64), and 25+ OS-CPU target layers. It also incorporates many graphical widgets and SCADA like behaviour with PascalSCADA and other components. There are wrappers for LibUSB.
I would use Microsoft Visual Studio to develop the GUI. They offer a free version called Express. I would use the C# language but MSVS supports other languages as well so just choose whichever you're most comfortable with. The best thing about MSVS is that there are millions of developers out there, which means that you will be able to search for and find lots of examples for how to use an RS-232 COM port or USB interface. I'm guessing that you'll be able to find GUI objects for graphing and other objects as well. (The basic stuff like buttons and edit boxes is all built into MSVS.)
BTW, you need to sort out whether you're using an RS-232 COM port or a USB interface. They're both serial interfaces but they're not the same thing. Either could work.
Apple has killed Carbon for 64 bit applications. I've got a pile of legacy code that targets carbon UI widgets that I'd like to keep alive for a while. Most of it is in the form of plugins and bundles that will have to go 64-bit in sync with their host platform.
The choice that Apple seems to be assuming is to throw all the legacy code away
and rewrite using Cocoa. It's not going to happen in the short run, if only because
the same legacy code is tied to a PC binding as well.
I'm considering 3 Options
(1) Dive into cocoa, create a compatibility package that supports the small subset
of carbon that I actually need.
(2) use Cocoatron as the new target. In the short run bridge carbon-to-cocotron, and maybe in the longer run convert to cocoatron native for both mac and pc. (ref: http://cocotron.org/)
(3) use QT as the new target. See option (2). (ref: http://qt.nokia.com/)
What I would really prefer is a fourth option, such as a bootleg copy of the 64 bit
Carbon beta that Apple killed, or a compatibility package explicitly intended just
to emulate carbon.
I would recommend you choose option 1. Creating a Cocoa UI wrapper for your code will likely not be as complex as you think. A common way to create a cross-platform app is to create the bulk of the app in cross-platform C++ and use Cocoa/Objective-C++ for the Mac UI and one of the Windows APIs for the Windows UI.
This option also has the advantage that it is fully supported by Apple and the APIs are stable and mature.
Cocotron is a nice idea but as of now it's not mature enough (in my opinion) to provide a robust cross-platform solution. I know there are successes with it but the sample size is small.
Qt is an option. However, it suffers from a very un-Mac-like UI. Using a Qt app on the Mac always feels like a quick port rather than a native app, and this is unlikely to ever change.
The "bootleg Carbon runtime" is just a fantasy, there is simply no way to get that working reliably and absolutely no chance to distribute it. You will need to find another way.
Use a text UI library. The Curses library used to be a popular option, but it is limited by copyrights.
Fortunately, there is an uncopyrighted version available.
This is called the "Console" mode.
Depending on your development environment and language of choice, it can be as simple as Ctrl+Shift+N, "Console Project" (in Visual Studio), or tweaking compiler flags (for C++). Every IDE/language provide a way to do this.
In Windows, the Console operates in two ways. Firstly, any project can create, attach to, and modify any number of console windows whenever it wants. Secondly, with a special flag in the EXE, the project will start up already attached to a console.
The latter operates subtly differently from the former. If you want a "normal" console application, I strongly suggest against creating and attaching to consoles. Just use the Console mode compiler setting.
Clipper was a popular way to do this in DOS.
I guess this is an old Clipper program. I so, there is still active support and even GUI libraries. I suggest you try xharbour. It's not DOS anymore but pure windows based. There is a free version and a pay version (visual xHarbour). With this tool you can even access SQL databases and it's 100% clipper compatible.
I would like to build a graphical application that must work on at least Windows, Linux and MacOS. I would like to know what do you suggest I should use.
I have some experience with Java and C++ but I thought about using Java Swing first. What do you think or further suggest (like maybe tools or frameworks)? I also may be needing to connect to a PostgreSQL database to store data.
Java is probably the simplest way to get your application working on all 3 platforms as well as to add database support. All of these are equally possible in C++, but it definitely involves more work because you need to learn to use a cross-platform widget toolkit. Also, C++ database drivers usually have wildly varying designs but Java presents a unified interface via JDBC - this also means that you can change your underlying DB at any time without having to change your code.
I would use the Qt platform from Nokia. It supports all the OSes that you've mentioned and has also database connectors for PostgreSQL but also for MySQL, SQLite, etc.
It also has a very nice IDE, the QT Creator that you can use should you pick Qt.
I would suggest Qt too. Qt has seen very good development recently, their examples and documentation base is quite large, and the LGPL license is flexible too, for creating proprietary software. It has a good Qt Creator IDE, a Qt GUI Designer. Plus is has quite a number of modules, enabling it to be used in conjunction with other language developed apps/libraries. And, it is used in commercial/public apps like Google Earth, Skype (maybe only the linux version). So, it has a good history of reliability. And yeah, for Database, it has modules, like Qt-Sql. Another advantage you get over java is speed.
wxWidgets does cross-platform easily enough, using available native toolkits. You could probably use a ORM for the database part, but I don't have enough experience using them under C++ to provide an actual informed opinion there.
GTK is cross-platform. Pidgin uses it and manages to get away with being generally considered a fully-cross-platform app. The installer size is a problem, though.
How do you port a Cocoa/Mac application to Windows? I mean how would you go about it? Assume the app was written with Objective-C and Cocoa, there's nothing fancy going on, no "engine" that could be factored out, etc.
Rewrite from scratch? I don't think there will be huge overlaps between the Mac and Windows codebases, right?
I have doubts about cocotron.
Its not clear from the cocotron website that cocotron is actually production ready yet. Id suspect that it would be possible to start new app development and use cocotron constantly to maintain and test windows builds on the go.
But to retrofit it into an existing project might be a much larger task. There are also no alternatives to cocotron - other than perhaps gnustep.
The practical approach to cross platform development involves developing the non gui components of your application, once, in C or C++. And then using a cross platform GUI library like QT - which is VERY good at generating and using native UI where possible or faking it where not. Please DO go to qt.nokia.com and download the latest build of QTCreator for windows and mac - See how the same QT application looks and feels very convincingly native on both platforms.
If QT doesn't provide a native enough solution, then you need to develop your GUI twice :- once in Cocoa, and once in Win32. The cocoa GUI would be in objective C of course, the Win32 GUI in C/C++.
Your non gui application code would - written in c++ - not be able to call Objective-C directly, but its not hard to write shim classes, implemented in .mm files - the provide a c++ interface, and wrap access to an objective c object or class.
You are also going to have to come up with an alternative to CoreData on windows - perhaps sqlite? Given that XCode has integrated support for the sqlite framework, and testing multiple code paths is, well, more work - perhaps dropping CoreData in favor of a common layer is a better approach?
The problem with Objective C is its very poor support on any platform that is not OS X. You can attempt to use the Cocotron, but I wouldn't consider it production ready yet.
For portability, a re-write is in order. With judicious use of standard C or C++ for the "core" of the application, you could still implement platform specific GUI code. If you don't like maintaining two GUIs, you can also try a toolkit such as Qt
Depending on which objects and framework you are using for your cocoa app, you might be able to get away with using gnustep, although the end result will probably look very weird to windows users, and the development environment might be a bit difficult to setup at first.
Are you aware of Cocotron? It looks like the project may have gone stale, but it's a good starting point anyway. It's a project to port Core APIs.
If your application is not cleanly separated (ie: a la MVC) then the only solution is a rewrite, I think.