Lost all Lua code

[oldgearguy]

yeah, well, after editing and saving on a regular basis, one time I tried to add another method and after compiling, saving, closing, I re-opened that panel only to find all the Lua code is gone.

I only see the built-in stuff. The panel itself seems ok and up to date, but all Lua is gone. I can open previous versions and see the (older) Lua and panel, but not the most current.

Why/where did all that get dropped form the panel file?
Build 5.6.34

[dnaldoog]

Oh no!

Did you set this button by any chance? Lua is disabled It'll nuke all your lua code when you reload!

If not, can you reproduce that behaviour?

[oldgearguy]

No, that wasn't checked. Here's what I've done/what I know.

I copied a version of my panel from the Mac to my Windows box (PCM80_v94.panel).
Opened it, tested it out, all good.
Opened the Lua editor, and selected 'Export methods to files'
Opened the modulator list, selected columns of interest and exported them as a CSV file.
CtrlrX created a PCM80_v94 directory, a lua directory below that and populated it with all the Lua files. So far, so good.

IT APPEARS that the 'export' option in the Lua editor is sticky. Every time I edited the _v94 panel and did a compile and save, my Lua changes are reflected in the files on disk. That's a nice bonus.

However, there appears to be some side effects. If I save edits as PCM80_v95, it seems to work but as soon as I try to open the new _95 panel, CtrlrX crashes on startup (I see a strncpy() and other things in the crash log). I cannot save a working version to anything other than PCM80_v94.
When CtrlrX crashes, it seems to leave the PCM80_v94/lua/lua files directory tree marked read-only.
I guess CtrlrX was in a funky state because I created a new method, did a compile and save all, but the newly created Lua file/method was not saved.
If you invoke a method that is either not created yet or misspelled, CtrlrX crashes.
During one of these crashes, the association between the panel and the Lua code was lost.

So now I have a directory full of good and mostly current Lua files, an updated panel I like with no Lua attached, and older versions that have both the Lua and panel stuff together.

I can go into the current panel and manually add 100+ new methods and copy the code into them one at a time and if I have to do that I will. I was hoping there might be an easier answer.
I tried copying all the stuff from the old panel Utility tab into the newer panel, but that was unsuccessful.

[dnaldoog]

I didn’t even know you could do that. It’s a feature I’ve never used or even felt I had to.

I’m going to look into that, but one thing you could try doing, is locating all the lua code within the XML tags and cutting and pasting into the new panel. That is probably bound to work. So just open the .panel in notepad++ (in Windows) or some editor in Mac and copy and paste into the 95 version and I think that should work. I’ve sometimes done that when I couldn’t open a panel that had become corrupted.

[oldgearguy]

I'll try that. I attempted to paste some of that Lua XML directly into the Utility tab of the panel, but it didn't stay there even after a save.

I did the export because the panel is a mix of new stuff I wrote and a bunch of old Lua that I probably wasn't going to keep. However, modulators reference the Lua code so deleting them wholesale isn't smart. By exporting the Lua and the Modulator list, I can pull all that into Source Insight and then track down every place a method is used. It also makes it easy to find things like everywhere I do panel:getModulatorByName(0 or whatever and trace through calls and such.

It also means I can use Notepad++ to do easy column manipulation, indenting, find/replace across parts of files and so on.

Plus I can use Beyond Compare to see diffs between versions when the files and tables get really large.

EDIT - the copy/paste got me back to a decent state. I need to do the last round of updates, but it's about 98% current now, which is a huge step above yesterday's mess.

Thanks for the suggestion.

[oldgearguy]

Am I just good at this or what?

So - I have a group that starts out hidden and then gets visible once the user syncs with the hardware.
So far so good - this is solid and has been working 100% of the time.

I wanted to add a label that is shown when a user right-clicks on a control so they can enter a new value directly.
I created a label, moved it onto the group, unchecked the 'component is visible'.
I also added some methods to display the label and to update the control with the new value once entered.

I saved off the panel and closed it to make sure all the methods were available.

I opened the panel up and all the Lua code was gone. The panel size had dropped by a few hundred k.

All I can figure is somehow having a hidden object on a hidden group caused this failure since that was the only change.

I had a panel from Friday that I sent to the beta testers, but all the work done between Friday afternoon and today is gone.
Still not sure why any kind of failure/configuration would cause a save to delete all the Lua code.

[dnaldoog]

Are you using 5.6.34?

there’s a subtle bug with uiGroup that has been fixed in the latest version 5.6.35 as yet unreleased. In theory it fixes modulators getting discombobulated from their groups on rare occasions, but it’s hard to reproduce and the two people who complained about this problem haven’t got back to us to confirm whether it’s now fixed.

But I doubt that would cause such a massive crash as you experienced!

I always stay away from uiGroup and uiTabs and use layers or uiComponent for layout.

[dnaldoog]

Do you think you could reproduce that crash?

[damiensellier]

uiGroups is making the world collapse 😭

[damiensellier]

@oldgearguy Please try this version it's the latest pre-release installer for Windows :
CtrlrX-5.6.35-20260413-CtrlrMIDISettings-Windows.exe.zip

[oldgearguy]

I'll see if I can reproduce it. If I can break it (again) under .34, I'll download and try .35
I know what I tried to do.

Going to .35 when no one else has it doesn't seem like the safest choice.
If/when I release this as a standalone app, does the version of Ctrlr get bundled with it or does a user have to download and install the Ctrlr framework first?

re: Layers - I'm going to have to post up what I'm currently doing and then see if you all can suggest a way to use layers instead of groups.

[damiensellier]

it depends if you provide .pannel files or if you provide an exported instance (standalone, vst3 etc)

[oldgearguy]

I was going to provide an exported standalone instance.

[damiensellier]

@oldgearguy ok so you'd better use 5.6.34 or the stable release of 5.6.35 to come because your exported instance will copy the actual CtrlrX piece of software within your app.

[dnaldoog]

@damiensellier I think that CtrlrAbout.cpp window is still crashing on Windows 5.6.35-Maintenance

[damiensellier]

I don't know why to be honest, it's rock solid on mac and I put some safeguards for all pointers listed.
Can you please double check my code to see if you can find the culprit?
thanks

[damiensellier]

here's the suggestions by gemini:

I have reviewed your CtrlrAbout.cpp and CtrlrAbout.h files. You have successfully implemented the major safety patterns we discussed, such as caching the activePanel pointer and adding defensive if checks in resized().

The reason you may still be seeing crashes on Windows specifically likely relates to how Windows handles Component destruction order and Label/TextEditor updates from background threads or during a "Single Instance" export.

Here are the specific issues and the fixes needed to stop the Windows crashes:

1. The "Dangling Listener" Risk (Destructor Order)

In your destructor, you remove the listener from the logos, but your CtrlrAbout class is a Button::Listener. If a button is clicked and then the window is closed very quickly, Windows can sometimes dispatch the message to a class that is already partially destroyed.

The Fix: You should explicitly tell the buttons to point their listener to nullptr to ensure no messages are in flight.

CtrlrAbout::~CtrlrAbout()
{
    // Set listeners to nullptr explicitly before ScopedPointers delete the objects
    if (ctrlrLogo)         ctrlrLogo->removeListener (this);
    if (githubLogo)        githubLogo->removeListener (this);
    if (donateLogo)        donateLogo->removeListener (this);
    if (vst3AuJuceLogo)    vst3AuJuceLogo->removeListener (this);
    
    // Explicitly stop them from being able to trigger buttonClicked during destruction
    if (ctrlrLogo)         ctrlrLogo->setCommandID (0); 
}

2. Potential Null Access in updateVersionLabel()

This is the most likely culprit for the Windows crash. You call updateVersionLabel() inside the constructor. This method uses versionInfoLabel->insertTextAtCaret() and versionInfoLabel->setText(). On Windows, if the graphics context isn't fully initialized, calling insertTextAtCaret on a TextEditor can occasionally trigger a memory access violation.

Furthermore, versionInformationArray.getDescription() can return an empty string that might cause issues with certain JUCE TextEditor configurations.

The Fix: Add a safety check inside that method:

void CtrlrAbout::updateVersionLabel()
{
    if (versionInfoLabel == nullptr) return; // Safety check

    versionInfoLabel->clear(); // Clear existing text first
    for (int i = 0; i < versionInformationArray.size(); i++)
    {
        versionInfoLabel->insertTextAtCaret(versionInformationArray.getAllKeys()[i] + ": ");
        versionInfoLabel->insertTextAtCaret(versionInformationArray.getAllValues()[i] + "\n");
    }
}

3. Property Access Safety

In your constructor, when accessing properties from the activePanel, you use .toString(). If a property is missing in the XML of a user's specific panel, getProperty() returns a var::null. While toString() is usually safe, on some Windows builds, accessing a null property within a constructor can cause a hang.

The Fix: Use getProperty(Ids::name, "Default Name") to provide a fallback value.

4. Logic Error in resized()

There is a minor logic error in your resized() method that could cause a layout loop (and a crash) on Windows high-DPI screens:

• At line 476, you calculate height += 48; then set the bounds for instanceDescription.
• If singleInstanceHeight is calculated differently on Windows due to scaling, this height value might exceed the window's actual height, causing JUCE to try and re-size the window infinitely.

The Fix: Ensure the instanceDescription height is constrained:

height += 48;
if (instanceDescription)
{
    // Ensure the description doesn't go off-screen
    int descHeight = jmin(80, getHeight() - height - paddingSize); 
    instanceDescription->setBounds (proportionOfWidth (0.0200f), height, proportionOfWidth (0.9600f), descHeight);
}

Summary of file status:

• CtrlrAbout.h: The structure is correct.
• CtrlrAbout.cpp: Most safety checks are there, but adding the nullptr check in updateVersionLabel() and the listener safety in the destructor should resolve the remaining Windows-specific crashes.

[damiensellier]

@dnaldoog Let me know if those suggestions fix the crash ;)
Maybe CLaude AI has different views about that idk.

Thanks

[dnaldoog]

Will check it out - yes, I wrote that rather then try to fix it, because scanning through the code, it looked ok to my not so skilled eyes (ie basically just checking the destructor code)!

[damiensellier]

not to disturb the conversation, I opened an issue there : damiensellier#247
I wonder if it's crashing when opening the window or when closing, I don't use WIN so I can't try it. let me know in the issue above.
thanks

[oldgearguy]

Naturally, I cannot reproduce the crash. Tried for a couple hours, various combinations of activities. Sorry about that.

Two quick questions --

1. Dnaldoog -- is there an email I can use to send you a chunk of this stuff so you might be able to advise on using layers versus groups?
   I'm at: tmoravan@yahoo.com

2. Is there any cautions/downsides to using negative coordinates versus setVisible() to hide/show an object?
   IOW - use controls_inlvl:getComponent():setTopLeftPosition(-100, 100) and controls_inlvl:getComponent():setTopLeftPosition(212, 144)

instead of controls_inlvl:getComponent():setVisible(false) and controls_inlvl:getComponent():setVisible(true)