Language Recomendation

[danadak]

Hi, I have a need to write embedded applications where the client side is Windows runtime GUI.
I am looking for recommendations which language seems to be preferred. I had thought Python
'would be a good starting place until I realized, or at least think, it has no forms or GUI capability
inherent to its language, eg. its incomplete in that sense. Is .NET the foundation I have to tackle ?

I have been writing for many years, 4004, PDP8, various semiconductor testers like Teradyne, Sentry,
many UP ASM languages, some Basic, lots of embedded C, Fortran.

Regards, Dana.

[krho]

You can take a look at Lazarus IDE. That's FreePascal underneath.

[andersm]

Python comes with Tcl/Tk support in the form of the tkinter module. There are also other GUI libraries like wxPython. You could also give IronPython a shot. If you're going to be doing more Windows software I would still recommend learning C#.

[Kalvin]

One option is to separate the GUI and the business logic using loose coupling between the two. For example one can create the GUI using the tools / platform most suitable for the task, and then implement the business logic using the tools / platform most suitable for the task. The two system needs to have a way to pass the events and control (user actions and values from the input forms etc.) from the GUI into the business logic, and the business logic needs to have a way to pass data and status back to GUI.

I have used Qt GUI with Python (PyQt) is Linux environment successfully. Of course, one could use the Qt and C++ for implementing the GUI and the business logic if one desires to do so. Disclaimer: I have not used Python nor Qt nor PyQt in Windows environment, so I do not know how well they are supported.

[nctnico]

Either wxWidgets or QT offer mature solutions but don't expect to be able to draw forms. Drawing forms is a waste of time anyways because most GUIs need to be able to be scaled (especially when used both on a PC and embedded device). In my wxWidgets software the GUI is driven by formulas which calculate the size and position of all elements to create a scalable user interface.

[John Coloccia]

There's not really enough information about what the OP is doing to guess at a good solution, but I tend to use Visual Basic (VB.net now) for simple interfaces, and usually communicate to the embedded side via sockets or serial. I like doing it like this even if the interface and low level code are on the same system. It's just nice to have the two code bases completely decoupled.

[Kalvin]

Either wxWidgets or QT offer mature solutions but don't expect to be able to draw forms. Drawing forms is a waste of time anyways because most GUIs need to be able to be scaled (especially when used both on a PC and embedded device). In my wxWidgets software the GUI is driven by formulas which calculate the size and position of all elements to create a scalable user interface.

Qt has layout management and scalability which will take care of the resizing.

http://doc.qt.io/qt-4.8/layout.html
http://doc.qt.io/qt-4.8/scalability.html

http://doc.qt.io/qt-5/layout.html
http://doc.qt.io/qt-5/scalability.html

[rstofer]

It sounds to me like you want a Windows GUI to control an embedded device.  This sounds a lot like IoT (Internet of Things) and Microsoft has a platform for that.

If the GUI is to run only on Windows (not Linux), I would be using Visual Basic for the windows (buttons, knobs and dials) and communicating to the remote embedded device over some communication stream.  IoT uses Ethernet and that's pretty easy to do using VB.NET.  I have also used a simple COM port over USB where the embedded device was tethered.

You need to provide more details of your requirements if you want a refined discussion.  For my purposes, I would probably skip the Python/Qt approach simply because Visual Basic is easier to use.  I have written some GUI code using Python and a couple of different windowing libraries and it works well but it didn't seem as simple as the drag-and-drop approach of Visual Basic.

[tggzzz]

Hi, I have a need to write embedded applications where the client side is Windows runtime GUI.
I am looking for recommendations which language seems to be preferred.

Languages are easy; there are only a few different types and once each type is understood, a new language of that type is easy to pick up.

Concentrate on finding a library that not only does what you need, but also has associated libraries for the other aspects of your application, e.g. data pre-processing and comms and multithreading etc.

That approach has the advantage of showing why C++ is often a bad starting point.

N.B. frequently decent libraries are not tied to a specific operating system, in which case you haven't unnecessarily closed future doors.

[John Coloccia]

Honestly, it's really hard to imagine why a pro would choose QT or wxWidgets for a Windows application. One of the few good things I have to say about Microsoft is that their Windows development environment is orders of magnitude more advanced than anything else I've ever seen. If you're committed to Windows, Visual Studio is a slam dunk. I often wish Microsoft would enter the Linux/Unix market and create a similar development environment there.

[nctnico]

Honestly, it's really hard to imagine why a pro would choose QT or wxWidgets for a Windows application.

The answer is simple: platform independance. Microsoft is lightyears behind when it comes to being cross platform. Also deployability is way easier with a C++ application because you can link it into a single blob with no reliance on external DLLs (at least with wxWidgets using GCC; I don't know about Qt). Supporting different languages is also something Microsoft isn't very good at. Last time I looked you need to compile a DLL for each language. The GNU tools have the Gettext system which basically is a seperate file with the translations. No programmer needed to deal with multiple languages.

[John Coloccia]

Honestly, it's really hard to imagine why a pro would choose QT or wxWidgets for a Windows application.

The answer is simple: platform independance. Microsoft is lightyears behind when it comes to being cross platform. Also deployability is way easier with a C++ application because you can link it into a single blob with no reliance on external DLLs (at least with wxWidgets using GCC; I don't know about Qt).

Platform independence is irrelevant if you're writing a Windows application. The importance is overblown, IMHO. Windows has more market share than everyone else combined, several times over. Don't make life hard on yourselves. If you're writing a Windows app, don't tack on some made up requirement for cross-platform support, especially now that Visual Studio is free for individuals and still very reasonably priced for companies.

[westfw]

Visual Basic was surprisingly easy to use, and very "visual."  I was able to put together a simple windows GUI interface to a hardware "thing" in a couple of hours, without having ever programmed windows before, and without having used BASIC in the prior 20 years.  (Ok, I felt a bit ... dirty ... afterward.  But you can see why people stop there instead of learning "real" languages...)
There are 3rd party compilers that I think do similar things,  but provide portability between win/mac/linux (ie RealBASIC ?)

[nctnico]

Honestly, it's really hard to imagine why a pro would choose QT or wxWidgets for a Windows application.

The answer is simple: platform independance. Microsoft is lightyears behind when it comes to being cross platform. Also deployability is way easier with a C++ application because you can link it into a single blob with no reliance on external DLLs (at least with wxWidgets using GCC; I don't know about Qt).

Platform independence is irrelevant if you're writing a Windows application. The importance is overblown, IMHO.

Maybe in your world but certainly not in mine.

[igendel]

+1 for Lazarus. It has visual drag-and-drop components and handles them quite intuitively in the code as well.

Speaking of Object Pascal, Embarcadero's Delphi Starter Edition (Also C++ Builder Starter Edition) is currently offered for free, and it's even more convenient for Windows development, although the Stater Edition has some limitations (e.g. only compiles to 32-bit).

[danadak]

To answer the earlier poster, evb149, with more specifics on my applications.

Generally the client side for my designs is an embedded solution, sensor reading and conditioning,
like T, P, E, I.....nothing high speed. Client side mainly done in C and some ASM.

I want this in turn to be displayed and controlled by a windows GUI application, a host. Again no high speed
data. Maybe some data collection, graphing, etc. on host side for the sensor embedded clients output.

Additionally a host might be a control point, for example, a function generator client controlled over USB, where simple
commands and data are sent to generator and the generator re configures itself and generates signals
as stipulated by host.

Based on prior post in thread I am leaning away from Python and towards VB, it seems Python add on
GUI libraries an invitation to discontinued support as they are not "standards"......VB also because of
perceived broad based usage and .NET integration (do I even know what I am talking about here ?)


Regards, Dana.

[tggzzz]

Don't forget Microsoft's PlaysForSure (sic), and to lesser extent, Silverlight.

Personally I'd go for Python, because it will run on many cheap low power platforms, e.g. RPi. Naturally, YMMV.

[donotdespisethesnake]

I wouldn't bother with VB, go for C#, it's far superior.

[IanB]

I have a need to write embedded applications where the client side is Windows runtime GUI.
I am looking for recommendations which language seems to be preferred.

I think you need to be more specific than "Windows runtime GUI"? Do you mean phone/tablet, or do you mean desktop? Microsoft has a variety of different toolkits and programming environments depending on your needs and preferences, but if you want to support tablets this will focus your choices.

Whichever way you go, I strongly recommend using Microsoft's provided solutions. They will provide you with by far the most productive and effective path.

The simplest approach for the desktop is "Windows Forms". You can use this programming environment either with C# or with VB.NET (which is not exactly the same as "traditional" VB, which is now only used in legacy apps).

I'd recommend you do some reading around Microsoft's web pages and documentation to get a feel for what's on offer, and then maybe ask some more specific questions.

[ez24]

Labview ?

[John Coloccia]

I personally think vb.net is better than traditional vb. You can actually do real work in vb.net. VB was quite limited unless you didn't mind making things like ActiveX components to do more complicated stuff. But that's just my opinion.

[John Coloccia]

I personally think vb.net is better than traditional vb. You can actually do real work in vb.net. VB was quite limited unless you didn't mind making things like ActiveX components to do more complicated stuff. But that's just my opinion.

On contrary, I think ActiveX is wonderful and it really makes programming easy. It's horrible when used in a browser, but in a local program, it is wonderful.
VB6's OO model exposes just enough flexibility (encapsulation and very basic inheritance) while the nasty polymorphism is not there except for its built in functions.
From a non OO programmer's perspective (I started with C and VB), I like this type of simple OO more than complete OO like C++ or Java.

I don't think I said ActiveX is bad, but if the goal with VB is to do simple VB code, making ActiveX components is counterproductive.

[IanB]

I don't think I said ActiveX is bad, but if the goal with VB is to do simple VB code, making ActiveX components is counterproductive.

You don't make ActiveX components yourself, you make use of a library of existing components written by other people.

But the advantage with VB.NET is that your library of components is larger and more standard and more available than with VB6.

[John Coloccia]

I don't think I said ActiveX is bad, but if the goal with VB is to do simple VB code, making ActiveX components is counterproductive.

You don't make ActiveX components yourself, you make use of a library of existing components written by other people.

But the advantage with VB.NET is that your library of components is larger and more standard and more available than with VB6.

That's kind of like saying that you don't need to write C code yourself...you just use other people's C code.

The old VB had serious limitations. It was essentially a very stripped down language that happened to support COM. You couldn't even do basic multithreading without burying it all in ActiveX, so anything that you wanted to do that had any sort of threading required writing an ActiveX component to do it. It's not a big deal, but VB.net is a vast improvement over VB6, for example. It's really a complete language, and is mostly equivalent to C#. There's a little additional complexity over the old VB, but what you get in return is a vast reduction in complexity when you're doing something more advanced than just building a simple GUI.

It does beg the question why you would use VB over C#. I think VB syntax is just simpler for simple applications.

[IanB]

That's kind of like saying that you don't need to write C code yourself...you just use other people's C code.

That is correct. I was saying that. At the time I was using VB, not only did I not know how to write ActiveX components, I didn't know how to write C code either. I was using VB in the way that many (most?) other people were using it, as a "glue" to join other components together.

It is quite possible for people to construct an assembly out of pre-built components, without necessarily knowing how to design and make those components. Just as it is with electronics...

[westfw]

VB6 is a wonderful RAD tool, unfortunately is was long gone.

I'm pretty sure that the VB I used previously and subsequently recommended was VB6 or earlier; I didn't realize that there had been major changes :-(

[IanB]

I'm pretty sure that the VB I used previously and subsequently recommended was VB6 or earlier; I didn't realize that there had been major changes :-(

And will continue to be. These days it seems Microsoft can't stick with the same thing for more than three years before retiring it and moving on to the next latest and greatest technology 

[John Coloccia]

That's kind of like saying that you don't need to write C code yourself...you just use other people's C code.

That is correct. I was saying that. At the time I was using VB, not only did I not know how to write ActiveX components, I didn't know how to write C code either. I was using VB in the way that many (most?) other people were using it, as a "glue" to join other components together.

It is quite possible for people to construct an assembly out of pre-built components, without necessarily knowing how to design and make those components. Just as it is with electronics...

The point is that VB.net no longer requires doing it like that. Your approach may work if everything you need happens to exist as a component that does precisely what you want it to do. In general, that's not the case. It could be true in your particular case because of what you happen to be using it for. Believe me, Ian, I've spent many many hours writing ActiveX controls because someone else was hell bent on using VB. The situation today with VB.Net is much improved.

This all started because someone claimed that he old VB was better or simpler. In fact, for all but very simple drag and drop GUIs, the situation today MUCH simpler because you can do so much natively.

VB6 is a wonderful RAD tool, unfortunately is was long gone.

I'm pretty sure that the VB I used previously and subsequently recommended was VB6 or earlier; I didn't realize that there had been major changes :-(

Just download Visual Studio and check it out. I doubt you'll be upset when you see what it's like.

[IanB]

The point is that VB.net no longer requires doing it like that. Your approach may work if everything you need happens to exist as a component that does precisely what you want it to do. In general, that's not the case. It could be true in your particular case because of what you happen to be using it for. Believe me, Ian, I've spent many many hours writing ActiveX controls because someone else was hell bent on using VB. The situation today with VB.Net is much improved.

I know. In those observations I was speaking in the past tense, i.e. two decades ago, way back when, when I happened to be writing some VB code. That was before I knew how to code in C, C++ or C#, before .NET was even conceived. The situation is quite different today.

Today, I fully agree with you. The .NET environment is much more complete, and anyone today would be crazy not to make use of it.

[John Coloccia]

I know. In those observations I was speaking in the past tense, i.e. two decades ago, way back when, when I happened to be writing some VB code.

Hey, do you remember what it was like if heaven forbid you ever launched a program without saving your work first, and it happened to get stuck in a loop somewhere or something like that...and then it all locks up and you loose all of your work. The funny thing is that there's a way to kill the running program and get back to normal, but I didn't learn about it for years. I'm also one of those people who thought Roy Orbison was blind. Found out he wasn't just a few years ago. It happened to come up in conversation with a friend recently. I thought we would have a good laugh over my own stupidity. Instead he said, "What do you mean? He WAS blind!"  I'm still not sure if he believes me or not.