Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Labview GUI in C++
Esam
Member
11-19-2002 08:00 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Is it possible to use Labview for the GUI of my software if most of the code is written in C++? I would have to be able to send a message to the C++ part of my code(user clicks/input) and receive a message back from it(output to the user). Is it possible to have this sort of interaction? I don't think its really a dll call because i'm not really calling a function once, both would have to be running simutaneously... A quick response would be great!
Greg_McKaskle2
Trusted Enthusiast
11-19-2002 11:36 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
> Is it possible to use Labview for the GUI of my software if most of
> the code is written in C++? I would have to be able to send a message
> to the C++ part of my code(user clicks/input) and receive a message
> back from it(output to the user). Is it possible to have this sort of
> interaction? I don't think its really a dll call because i'm not
> really calling a function once, both would have to be running
> simutaneously... A quick response would be great!
Most things are possible given enough debugging time, but what you
describe is potentially complicated.
You can build the GUI in LV, no problem there. You can either detect
value changes and attribute changes via polling, or you can use the
event structure in 6.1. Typically you would build some s
ort of state
machine or event handler to deal with the events. You still need one,
but each of these diagrams need to communicate to the C++ code.
If these are done as DLL functions, they can work as callbacks. This
simplifies the synchronization of things in the DLL. If you want the
DLL to have a thread that is always running, fine, but you will need to
be able to post an event or send a message of some sort to the DLL. The
message delivery could easily be calling a function in the DLL and
having that put something in a queue for the C++ code, or it could ride
on top of the Windows machinery and use Windows messages. Either way,
be sure to have good protection between handling different messages as
they arrive, especially if they are somehow grouped or order dependent.
Greg McKaskle
> the code is written in C++? I would have to be able to send a message
> to the C++ part of my code(user clicks/input) and receive a message
> back from it(output to the user). Is it possible to have this sort of
> interaction? I don't think its really a dll call because i'm not
> really calling a function once, both would have to be running
> simutaneously... A quick response would be great!
Most things are possible given enough debugging time, but what you
describe is potentially complicated.
You can build the GUI in LV, no problem there. You can either detect
value changes and attribute changes via polling, or you can use the
event structure in 6.1. Typically you would build some s
ort of state
machine or event handler to deal with the events. You still need one,
but each of these diagrams need to communicate to the C++ code.
If these are done as DLL functions, they can work as callbacks. This
simplifies the synchronization of things in the DLL. If you want the
DLL to have a thread that is always running, fine, but you will need to
be able to post an event or send a message of some sort to the DLL. The
message delivery could easily be calling a function in the DLL and
having that put something in a queue for the C++ code, or it could ride
on top of the Windows machinery and use Windows messages. Either way,
be sure to have good protection between handling different messages as
they arrive, especially if they are somehow grouped or order dependent.
Greg McKaskle
