03-27-2023 08:12 AM
So, I have a working .exe, does everything I want it to.
I have the relevant VI that the .exe was built from (it has been modified and as a result, isn't really doing what I want it to)
There is no version control in place (we are currently implementing it, so of the VIs we have are stored very badly causing conflicts)
Is there a way of opening the .exe so that I can extract the VI?
03-27-2023 08:24 AM - edited 03-27-2023 08:25 AM
Hi LVIEWPQ,
@LVIEWPQ wrote:
Is there a way of opening the .exe so that I can extract the VI?
Well, there are ways to see the VI tree inside the exe.
BUT: usually inside an exe the VIs are stored without their block diagram. So all you will get is the frontpanel/connector pane and the labels of input/output fp elements…
(Did you enable debugging in your exe when building it?)
@LVIEWPQ wrote:
There is no version control in place (we are currently implementing it, so of the VIs we have are stored very badly causing conflicts)
Now you know about the importance of using a SCC tool.
You even don't have an (older) backup of the source code?
03-27-2023 08:31 AM
@GerdW wrote:
Hi LVIEWPQ,
@LVIEWPQ wrote:
Is there a way of opening the .exe so that I can extract the VI?
Well, there are ways to see the VI tree inside the exe.
BUT: usually inside an exe the VIs are stored without their block diagram. So all you will get is the frontpanel/connector pane and the labels of input/output fp elements…
(Did you enable debugging in your exe when building it?)
@LVIEWPQ wrote:
There is no version control in place (we are currently implementing it, so of the VIs we have are stored very badly causing conflicts)
Now you know about the importance of using a SCC tool.
You even don't have an (older) backup of the source code?
It's not my VI or .exe
The person who built it did so, then modified the VI.
There's no version control at all, so once it's modified the old version disappears.
03-27-2023 08:38 AM
Hi LVIEWPQ,
@LVIEWPQ wrote:
It's not my VI or .exe
So you want to "hack" someone else's code?
That's considered "illegal" (under certain conditions) in some countries…
Ask the author of that software about the changes made to the software!
03-27-2023 08:39 AM
Can I Retrieve the LabVIEW Block Diagram from a Built Executable?
With the Application Builder's default options, it is not possible to retrieve the block diagram of a VI after it has been compiled into an executable.
When creating an executable in the LabVIEW Application Builder, you can check the Enable debugging option in the Advanced menu to build the block diagram into the executable, so that you can follow its execution. This way you can show the application's block diagram both in the development machine, as well as using remote debugging with another machine.
03-27-2023 08:45 AM
@LVIEWPQ wrote:
@GerdW wrote:
Hi LVIEWPQ,
@LVIEWPQ wrote:
Is there a way of opening the .exe so that I can extract the VI?
Well, there are ways to see the VI tree inside the exe.
BUT: usually inside an exe the VIs are stored without their block diagram. So all you will get is the frontpanel/connector pane and the labels of input/output fp elements…
(Did you enable debugging in your exe when building it?)
@LVIEWPQ wrote:
There is no version control in place (we are currently implementing it, so of the VIs we have are stored very badly causing conflicts)
Now you know about the importance of using a SCC tool.
You even don't have an (older) backup of the source code?
It's not my VI or .exe
The person who built it did so, then modified the VI.
There's no version control at all, so once it's modified the old version disappears.
Without version control you would have to depend on change documentation such as; Block Diagram notes, VI History (Ctrl + Y ) a ReadMe file or an Engineering Change Order. None of those replace a SCC repository although, each can be a valuable addition to one.
If debugging is not enabled in the exe you cannot see the Block diagram. Under no circumstances can you simply change the compiled object back into a VI. Like a cucumber, once it is pickled you have a pickle and can't turn it back into a cucumber.
03-27-2023 08:53 AM
@GerdW wrote:
Hi LVIEWPQ,
@LVIEWPQ wrote:
It's not my VI or .exeSo you want to "hack" someone else's code?
That's considered "illegal" (under certain conditions) in some countries…
Ask the author of that software about the changes made to the software!
More of the inherited code problems.
Created a VI > Built exe > modified VI for use elsewhere
The original VI used to build the exe has been modified and now doesn't produce the same results on the original machine.
03-27-2023 10:44 AM - edited 03-27-2023 10:47 AM
@LVIEWPQ wrote:
Created a VI > Built exe > modified VI for use elsewhere The original VI used to build the exe has been modified and now doesn't produce the same results on the original machine.
Whenever I build an exe I also build a source distribution, to be zipped and backed up under the version number of the current build (... with a fancy automated custom tool using the builder API). I have the full set of VIs for any version ever released and can easily backtrack if there is a new bug).
03-27-2023 11:33 AM
Hi,
@altenbach wrote:
Whenever I build an exe I also build a source distribution, to be zipped and backed up under the version number of the current build.
We just create a tag in our SVN repository with the version number of the EXE…
03-27-2023 12:11 PM
@LVIEWPQ wrote:
@GerdW wrote:
Hi LVIEWPQ,
@LVIEWPQ wrote:
It's not my VI or .exeSo you want to "hack" someone else's code?
That's considered "illegal" (under certain conditions) in some countries…
Ask the author of that software about the changes made to the software!
More of the inherited code problems.
Created a VI > Built exe > modified VI for use elsewhere
The original VI used to build the exe has been modified and now doesn't produce the same results on the original machine.
Wakeup call to standardize your process, documentation and source control. This is an excellent example of what a new engineer has to go through if someone left the org without documenting and storing the source somewhere.