11-04-2019 02:28 AM
Hi guys,
My desktop already installed with LabVIEW, and I received a LabVIEW created executable file from vendor. I would like to make modification on the code so how should I do this?
11-04-2019 02:58 AM
Hello
You cannot modify the code or the working with just the .exe file. You need the source code to modify or add anything to your software.(by source code I mean .lvproj and/or .vi files)
-Rahul
Hit KUDOS for Thanks
11-04-2019 03:59 AM
@sjgiap wrote:
Hi guys,
My desktop already installed with LabVIEW, and I received a LabVIEW created executable file from vendor. I would like to make modification on the code so how should I do this?
You ask the vendor for the code.
/Y
11-04-2019 05:33 AM
Or learn to hack really, really (X10) well.
The things you can do with a build executable (LabVIEW or any other really) has little to do with software engineering.
Any\all software can be modified given enough time, but it usually isn't the way forward.
It might not be legal to modify the executable. Usually, you either have the rights to do it, or you don't. If you do, you should be able to get the source, if you don't it's probably illegal to hack the executable. Unless the source code got lost of course, Than you're better of starting from scratch.
11-04-2019 03:55 PM - edited 11-04-2019 03:55 PM
@sjgiap wrote:
Hi guys,
My desktop already installed with LabVIEW, and I received a LabVIEW created executable file from vendor. I would like to make modification on the code so how should I do this?
You need the SOURCE CODE to do that
You can not take a compiled LabVIEW executable and generate the LabVIEW source code from it just like you can't generate the C source code from a complied C program.
11-04-2019 08:47 PM
Thanks for the feedback. Once I get the source code from vendor, how do I modify the code and yet able to use back the same .exe file? (i.e. amend on the code without rebuilding the executable file). The main objective is that we need frequent code update and we wanted to do it fast without rebuilding .exe every time.
11-04-2019 10:24 PM - edited 11-04-2019 10:27 PM
You would need to build a new executable. That's not the time limiting step and is trivial.
How much LabVIEW experience do you have?
Maybe you should explain what kind of "modifications" you are planning to do. Change algorithms? Just change some default settings? Expose more settings in the UI? Debugging?
Maybe you are approaching this wrong.
11-04-2019 11:06 PM
@altenbach wrote:
You would need to build a new executable. That's not the time limiting step and is trivial.
How much LabVIEW experience do you have?
Maybe you should explain what kind of "modifications" you are planning to do. Change algorithms? Just change some default settings? Expose more settings in the UI? Debugging?
Maybe you are approaching this wrong.
I'm worried as well. Judging from the kinds of questions asked, I'm wondering whether the OP has the experience to make this endeavor a successful one. Seems a bit dangerous to me.
11-05-2019 04:26 AM
@sjgiap wrote:
The main objective is that we need frequent code update and we wanted to do it fast without rebuilding .exe every time.
Making a new executable takes 1-15 minutes.
Making a plug-in architecture takes months if not years to perfect. Even when knowledgeable. And even than it's lots of work maintaining it.
You can actually run VIs in any LV executable, avoiding the need to build executables. I'm not sure what the point would be, but you can if you must.
Why do you want to avoid new executables? In general it makes your life a lot easier. The only problem is when IT prohibits installation of new executables. Sometimes installation is not needed though, and you can simply replace the .exe with the new one. Or make a VI launcher executable, but that will have unexpected side effects (aka lots of work).
11-05-2019 06:20 AM - edited 11-05-2019 06:21 AM
Are you still developing the software? Something that is considered "finished" should never have to undergo changes at such a rate that building an executable takes too long.
I think we need to understand why the software needs to be in constant flux like that. This just doesn't sound like a good strategy to me.