A cruel prank by AppBuilder doing exactly what it was told to do...

[Aristos Queue]

So I have this bug report that AppBuilder fails to build this one particular app whenever the "remove polyVIs and typedefs" option is enabled. The top-level VI breaks during the build.

I try some of our usual debug approaches and don't find anything, so I hack up AppBuilder a bit so that when I get to the end of the build, I can open up the broken VIs and see what they look like. And I see this:

Where the heck have all the class methods gone? They're in memory at the start, missing at the end. That shouldn't happen! So I set up a trap to detect when the VIs go missing. I'm working in a debug build of LV with a lot of extra guards and logging turned on, so it takes about two hours to run this build. And I get nothing. So I rework my trap, thinking I've coded something wrong. Four times I do this over the course of yesterday, working on other issues while the build runs. Four times -- roughly 8 hours -- nothing. The VIs swear they're all in memory and the caller should know about them. 

This morning I come in and, for some reason, I happen to double-click on one of those ? nodes. And, lo, the missing VI opens. Say what? Turns out, AppBuilder had stripped all the VI icons out (saves space in the built EXE to ditch all those unneeded images), so they all render as the ? icon.

I have no idea what's actually broken, but it ain't that all the class methods have gone away. One wasted day. *head bang*  *head bang*  *head bang*

Yet another reminder -- as if I needed it -- that computers only do what we tell them to do. And they do it very precisely.

[ShaunR]

It's the nature of the beast.

I had something similar today but not quite on the same scale. Every time I tried to build a zip archive with the option "Recurse Directories" .. it didn't. So I went through the code checking paths and and found it was because the boolean wasn't being set for some reason.  So having gone down the hierarchy checking hte file paths I then went back up checking the boolean only to find that the control on the front panel wasn't wired to the unzip sub vi for that option. Now you might say DUH!  But in my defence, it wasn't obvious because two boolean controls where vertically compressed and the  wire of boolean control above  (which was a function to be worked on next and therefore expected to be unwired)  went underneath the "Recurse Directories" and came out looking like it's wire.. So if I had tried the other option  (Include Empty Dirs) it would have recursed and I would have known immediately rather than 20 minutes later . 

[LogMAN]

2 hours ago, Aristos Queue said:

so I hack up AppBuilder a bit so that when I get to the end of the build, I can open up the broken VIs and see what they look like.

Please share ?

2 hours ago, Aristos Queue said:

Yet another reminder -- as if I needed it -- that computers only do what we tell them to do. And they do it very precisely.

Amen.

I was working on a nasty bug for the past few days as well. The source code looked fine, but the application didn't do what it was supposed to do (or so I thought). As it turns out the executable did exactly what it was supposed to do. And I was looking at the latest code, testing old software...

Reminder:

1) Always include und update the version number in your executables (and configuration data if possible)!

2) Work with the source code you used to make the executable!

3) If you are experienced enough to skip points 1 and 2, see points 1 and 2!

[Michael Aivaliotis]

On 11/14/2018 at 7:38 AM, Aristos Queue said:

I happen to double-click on one of those ? nodes. And, lo, the missing VI opens. Say what?

The icon has a question mark but it's bold and solid. Not grey and dimmed. Missing VIs or nodes show up dimmed.

[hooovahh]

2 hours ago, LogMAN said:

Reminder:

1) Always include und update the version number in your executables (and configuration data if possible)!

2) Work with the source code you used to make the executable!

3) If you are experienced enough to skip points 1 and 2, see points 1 and 2!

We use a PreBuild action, which can set the build number of an EXE to the SVN commit version.  This means that we'll have software 1.3.1.384 where commit 384 is the source that made that EXE.  Having it in the EXE means Windows can tell me what version it is even if I can't run my application and get to an About Screen.  It isn't seamless but it works well enough.

[Gribo]

Here is something for the idea exchange - the missing icon indicator should be visually different from the missing VI indicator.