How to retrieve an Id as a string?

[Ted-juh]

I made an extra class that opens a dialogwindow with some options. I also added some FileProperty's to set a path to files in the propertycomponent. For instance: Ids::panelBuildFolder.

It's all working including the creation of a batch file. But now I want to get the path from the ID's:: panelBuildFolder which resides in CtrlPanel.cpp to add it to the batch file. But so far no dice. The string is empty or when I change too much, results in errors.

But almost everything is done with those IDs. So, how do I use the Id in another Class? Someone care to shine some light on it?

[damiensellier]

Are you talking about : panel:getProperty("yourPropertyName") ?

For exemple : local myInputDevice = panel:getProperty("panelMidiInputDevice") will return the property Value String for panelMidiInputDevice.

[Ted-juh]

Ok, we are on the same page now 😉

Still. Do I need to point to the ValueTree somewhere in my class? In the private section of the .h file perhaps?

[damiensellier]

Can you please post the part of your code you want to add here and where it's supposed to be located?
All components have their own valueTree already. Definitions of function have to be added in the headers .h but your IDE will tell you if needed anyway.
That should be pretty easy to get the value of a property from ctrlrPanel.cpp since it's top level you can easily reach all its child components and their respective valuetree for props.

[unityconstruct]

Sniffer snippet that may help using getObjectTree() -might need to work off panel or panel.getParent() or similar
My assumption is these properties are - in part - what is in the CtlrlrPanelPropertyEditor

result = panel:getComponent("cbVoice1-Filter"):getObjectTree() what(result) console(tostring(result:getNumProperties())) for i=1,result:getNumProperties(),1 do console(tostring(result:getPropertyName(i)) .. " : " .. tostring(result:getProperty(result:getPropertyName(i))) ) end

result = panel:getComponent("cbVoice1-Filter"):getObjectTree() what(result) console(tostring(result:getNumProperties())) for i=1,result:getNumProperties(),1 do console(tostring(result:getPropertyName(i)) .. " : " .. tostring(result:getProperty(result:getPropertyName(i))) ) end
`Object type [ValueTree]`
60
componentSentBack : 0
componentMouseCursor : 2
componentVisibleName : cbVoice1-Filter
componentLabelHeight : 14
componentLabelJustification : centred
componentLabelColour : ffffffff
componentLabelFont : <Sans-Serif>;12;0;0;0;0;1;3

[Godlike-Productions]

try

console (String(result:getNumProperties()))

Note S is capitalized

[unityconstruct]

hmm... like that syntax better. FYI:...while it works there, apparently it has no concat overload function

(still stuffing in the toolbox as recall thread on other inherent benefits elsewhere (memoryblocks?))

console(String(result:getPropertyName(i)) .. " : " .. tostring(result:getProperty(result:getPropertyName(i))) ) 

ERROR: class String: no __concat operator defined.

[Godlike-Productions]

String is a ctrlr specific function (not native LUA). You'll need to do something like
console (String(a..b))

L is a similar function
console (L(a..b))

Both should do type conversion so if a is a number and b is a string, it will still concatenate, in the examples above. The only exception to this is userdata and displaying hex, for example.

To display sysex in the console go here - https://ctrlr.org/forums/topic/solved-display-sysex-string-in-console/

For tables, there is a function called table.concat which should concatenate a table that can be displayed to the console.

Another option is console ((string.format("Str1 %s", "Str2"))) -- Str1 Str2

[Ted-juh]

@unityconstruct and @Godlike-Productions. I appreciate the help but it was already stated that I'm talking about developing in the Ctrlr Source Code instead of a panel.

@damiensellier. I pinpointed it to be the arguments given to the constructor. As an example for CtrlrDocumentPanel in the .h file constructing CtrlrPanelDocument:
CtrlrDocumentPanel (CtrlrManager &owner)
Then in the .cpp file:
CtrlrDocumentPanel::CtrlrDocumentPanel (CtrlrManager &_owner) : ctrlrEditor(0) owner(_owner)
And then add to the private section of the .h file:
CtrlrEditor ctrlrEditor CtrlrManager &owner

That seems to make the class accessible. However, the example given is not suitable in my case, I have to find out what I have to put there as arguments. Because I'm almost at top-level CtrlrPanel, I thought it would be:
MyClassName (CtrlrPanel *owner) (and the rest of the alterations)
but that still leads to errors. Probably basic C++ stuff but causing a headache for me.

[damiensellier]

I can't tell since I don't know what's your code. Maybe you had it right at first but you need a Listener callback in your class to pass the result as a message if you get your variable from a combobox or another type of widget.

The best thing to do is to copy the logic from something similar somewhere else in the code.

https://docs.juce.com/master/tutorial_listeners_and_broadcasters.html

[damiensellier]

@Ted-juh do you have your current code on a repository?

[Ted-juh]

It's not the listener/broadcaster I'm struggling with, that's working because I got a button in the propertycomponent that opens (launches) a dialogwindow, which get it's content from a separate class.

I need to make the IDs in CtrlrPanel accessible to another Class (The dialogWindow). But no matter if I set the arguments to "CtrlrPanel *panel" or "CtrlrPanel *owner" like in so many other Classes, they all come back as null thus making the IDs inaccessible. (I made an alert window that reports if it's null to prevent crashing Ctrlr before the DialogWindow is shown.).

I hope you understand that it's too much code added too 8/9 files already to post here in an understandable way. I'll see if I can upload it to my repository later tonight. Keep in mind that I use CMake now. It compiles on Windows but I don't have any clue whether it will compile on Mac.

[damiensellier]

Okay so just to recap, you want to get a CtrlrPanel tree property from an external class ?
From what I remember all CtrlrPanel Properties are accessible via CtrlrManager.cpp like the property panelFilePath :

void CtrlrManager::openPanelInternal(const File &fileToOpen)
{
	setProperty(Ids::panelLastSaveDir, fileToOpen.getParentDirectory().getFullPathName());

	ValueTree panelTree;

	if (fileToOpen.getFileExtension().startsWith(".b"))
	{
		panelTree = CtrlrPanel::openBinPanel(fileToOpen);
	}
	else
	{
		panelTree = CtrlrPanel::openXmlPanel(fileToOpen);
	}
	if (panelTree.isValid())
	{
		// Patch panelFilePath property to match the actual file
		panelTree.setProperty(Ids::panelFilePath, fileToOpen.getFullPathName(), nullptr);
		addPanel(panelTree, true);
	}
}

CtrlrPanel has CtrlrManager as owner. You probably have parenting issue :-) You would need to assign your new class to CtrlrManager as owner and will be able to get the property you want with something like :
String panelBuildFolderDirectory = owner.getProperty(Ids::panelBuildFolder);

I tried and could get ctrlrLastBrowsedFileDirectory this way, it's pretty similar to what you want if I understand.
String dirctrlrLastBrowsedFileDirectory = owner.getProperty(Ids::ctrlrLastBrowsedFileDirectory);

The most important is to assign your new class to the right owner, and CtrlrPanel props requires going via CtrlrManager anyway.

You can call the ctrlrProcessor and drill down to the manager the following way. This is is strictly if you call the property from a component owned by the top of the top level ctrlrProcessor (like the CtrlrStandaloneWindow.cpp) :

ValueTree panelTree = ctrlrProcessor->getManager().getInstanceTree();
String panelBuildFolderDirectory = panelTree.getProperty(Ids::panelBuildFolder);

ctrlrProcessor has access to the manager tree via getManager() so it's easy to get its properties like this.
Let me know if you found your way to your property. Sometimes it can be confusing, I had big issues to get some ctrlrEditor tree properties from ctrlrPanelProperties and if called directly it was causing crashes unless you go via ctrlrManager and go backwards.

[damiensellier]

Oh and also, do you update something when your property value changes via valueTreePropertyChanged (ValueTree &treeWhosePropertyHasChanged, const Identifier &property) ?

void CtrlrPanel::valueTreePropertyChanged (ValueTree &treeWhosePropertyHasChanged, const Identifier &property)
{
	if (property == Ids::yourUpdatedPropertyValue)
	{
		// Do your thing here
	}
}

[Ted-juh]

The repository is up. Just click my avatar here and go to the "Ctrlr_CMake repository. I created an extra branch named "Development" that should have all the changes and probably some more unrelated "deleted comments". Keep in mind this is CMake, you need to build the build folder yourself. (It has to do with the fact that the paths being created are "absolute paths" thus user-specific, so you can do an out-of-source build).

Comment out in CtlrlPropertyComponent.cpp line 313 to see the DialogWindow but as soon as you press ok, a file will be created and the crash happens upon trying to fetch the String panelBatchProjectDir.

Section to comment out:
if (owner == nullptr) {DBG("CtrlrButtonPropertyComponent::openDialogWindow - owner is null"); AlertWindow::showMessageBox AlertWindow::WarningIcon, "Warning", "Owner is null."); return; }

I'm reading it over and over, what you wrote. Although it makes a lot of sense. I still struggle to understand why one class uses "CtrlrPanel *panel", the other one uses "CtrlrManager *owner" and the other one uses "CtrlrPanel *owner". I guess it has to do with the fact Ctrlr can open multiple panels at the same time and the Manager controls all the trees for the different panels. Thus I need to call CtrlrManager?
I'm going to give it a try this morning. Tremendous thanks for the heads up.

[Ted-juh]

I haven't found any solution yet. But after reverse-engineering some DialogWindows I have to re-think how I'm launching the DialogWindow. I'm doing it from CtrlrPropertyComponent.cpp file. It seems that's not the right approach. Other DialogWindows, especially the windows that are opened from the menubar, are handled by CtrlrWindowManager/ CtrlrWindowChildContent or are launched from another class. Another maze, another "Rabbithole".

It won't solve my parenting issue, but I rather add to the source code the way it's done before in the source code. To keep it consistent.

On another note, is there any reason there are so many "#ifndef __headerName.h/ #define __headerName.h instances? Can't they just be replaced with #pragma once? My compulsive disorder is reaching high limits with all the comments and auto-generated content from the Introjucer.

[damiensellier]

Alright so I saw you added in ctrlrPanel.cpp the following properties :

	setProperty(Ids::panelBatchProjectDir, "");
	setProperty(Ids::panelBatchVsDevCmdPath, "");
	setProperty(Ids::panelBatchMSBuildPath, "");
	setProperty(Ids::panelBatchDAWPath, "");
	setProperty(Ids::panelBatchBuildScript, 0);

https://github.com/Ted-juh/Ctrlr_CMake/blob/ddfa2cd332887d2af31b50b4edd5759980b8380d/Source/Core/CtrlrPanel/CtrlrPanel.cpp#L126C19-L126C39

I guess you want to display a dialog to edit the path when clicking on a button.

You set those properties the following types in ctrlrIDs.xm like this :

  <id name="panelBatchProjectDir"           text="Path to Project Directory"                        type="FolderProperty" />
  <id name="panelBatchVsDevCmdPath"         text="Path to Visual Studio VsDevCmd.bat"               type="FileProperty" />
  <id name="panelBatchMSBuildPath"          text="Path to MSBuild.exe"                              type="FileProperty" />
  <id name="panelBatchDAWPath"              text="Path to DAW"                                      type="FileProperty" />
  <id name="panelBatchBuildScript"          text="Execute Build Script"                             type="ActionButton" />

https://github.com/Ted-juh/Ctrlr_CMake/blob/ddfa2cd332887d2af31b50b4edd5759980b8380d/Source/Resources/XML/CtrlrIDs.xml#L114C1-L119C123

You added CtrlrFolderProperty type in CtrlrPropertyComponent:

CtrlrFolderProperty::CtrlrFolderProperty(const Value& _valeToControl) : valueToControl(_valeToControl)
{
	addAndMakeVisible(path = new Label(""));
	path->setText(valueToControl.toString(), dontSendNotification);
	path->addListener(this);
	path->setColour(Label::backgroundColourId, findColour(ComboBox::backgroundColourId));
	path->setColour(Label::outlineColourId, findColour(ComboBox::outlineColourId));

	addAndMakeVisible(browse = new TextButton("Browse", "Browse"));
	browse->addListener(this);
	browse->setConnectedEdges(TextButton::ConnectedOnRight);
	setSize(256, 48);
}

https://github.com/Ted-juh/Ctrlr_CMake/blob/ddfa2cd332887d2af31b50b4edd5759980b8380d/Source/UIComponents/CtrlrPropertyEditors/CtrlrPropertyComponent.cpp#L163

https://github.com/Ted-juh/Ctrlr_CMake/blob/ddfa2cd332887d2af31b50b4edd5759980b8380d/Source/UIComponents/CtrlrPropertyEditors/CtrlrPropertyComponent.cpp#L702

Since you are dealing with directory paths maybe the best way would be to show a native or juce "FileChooser" and get the current directory from the property text label as "initialFileOrDirectory" just by getting the property label content with getText().
You don't need to reach the valuetree directly, you already have its string representation in the property label. Your ctrlrPanel directory properties fields are going to be "listened" and will be updated via the FileChooser getResult().

https://docs.juce.com/master/classFileChooser.html

All the SpecialLocationType will be very useful for your project to be perfectly working on all platforms https://docs.juce.com/master/classFile.html#a3e19cafabb03c5838160263a6e76313d

The closest property editor would be the CtrlrColourEditorComponent which triggers the popup colour piccker on mouse down : https://github.com/damiensellier/CtrlrX/blob/9bd521e12b2f1073dfdb10ef5f6bcf5869864f66/Source/UIComponents/CtrlrPropertyEditors/CtrlrPropertyComponent.cpp#L445

I think#ifndef markup guards from JUCE v3 or v4 was replaced by #pragma once in JUCE v5 when they replaced Jucer by Projucer. Ctrlr was started on early JUCE 3 if I understand and upgraded along the way. hence the mix of both. There's a lot of widgets having extra markup at the bottom for the old Jucer which can be cleaned up too.

[damiensellier]

I thought about your issue while doing shopping :-)
First of all, are the property lanes to your custom directories displayed properly at the right place in the property pane with their respective empty fields ?

Note that you don't need a button to open a dialog you can just trigger it on a mouseDown event on the property field. It will save you 1 step.

You already have a full demo of the way path-to-directories are implemented with Ids::panelFilePath. panelFilePath property is also stored in the ctrlrPanel tree, then, it's really close to what you need. just search for it in your IDE.

The best way would be to duplicate the method for your custom feature. If you really need a dialog with the fileChooser go with my post above, if you just need to store them without mods just go for a type="readOnly" like Ids::panelFilePath.

The fileChooser will work a bit like the colourPicker CtrlrColourEditorComponent, I implemented it in v5.6.29
https://github.com/damiensellier/CtrlrX/blob/9bd521e12b2f1073dfdb10ef5f6bcf5869864f66/Source/UIComponents/CtrlrPropertyEditors/CtrlrPropertyComponent.cpp#L445

I don't know if it helps, but keep posting here, I'll try to help along your way. Good luck ;)
Damien

[damiensellier]

There's a demo of the directory chooser in the JUCE demoRunner app, it's located in the DialogsDemo.h, I think it will really help you :

[Ted-juh]

Reading your recap, I think you missed a few things that I added. No big deal. I decided to make a Gif to show how far I got with this project.

As you can see, everything is in the CtrlrPropertyComponent already. You can browse to files or a folder, everything is neatly saved into the XML. No problem. Clicking on "Execute Build Script" opens a DialogWindow (the CtrlrBuildScriptDialogWindow Class that I added) That gives you options to choose your preferred build. Clicking on OK should output the Script file, which works, see the left side of the gif. The script file gets written to because it shows a dummy text that I created in the first line. But Ctrlr Crashes when I try to get the string of one of the Paths in the property panes.

First of all, I have to give your "getResult()" suggestion a try. But I tried every possible combination to solve the parenting issue I mentioned. An if statement in CtrlrPropertyComponent that opens an alertwindow tells me every panel or owner that I try to call is null. Thus crashing Ctrlr when I create the script because it needs the Ids in CtrlrPanel or CtrlrManager to be accessible.

I hope it's more clear now. Off to try your suggestion.

[damiensellier]

Oh okay I spent some time checking all the files you updated in your repository. Everything is already there. You're really close to your goal.
I would need to work it on my side and spend some time to find the solution, but I don't have much time now.
To me it looks like the access to the property is not granted from one file to the other. And I already noticed I got crash when trying to read/write properties from one cpp to another.

Instead of working through your extra popup, it would be a great idea to see for the record if just by clicking your "execute build script" button you could export properly one of your file from the get go. To see if skipping on the popup and working straight from CtrlrPropertyComponent would let you grab the path and build your file correctly.

you should also try declaring CtrlrPanel &owner; in the private section of CtrlrBuildScriptDialogWindow.h and CtrlrPropertyComponent.h for the CtrlrFileProperty and CtrlrFolderProperty :
https://github.com/Ted-juh/Ctrlr_CMake/blob/ddfa2cd332887d2af31b50b4edd5759980b8380d/Source/UIComponents/CtrlrPropertyEditors/CtrlrPropertyComponent.h#L283
https://github.com/Ted-juh/Ctrlr_CMake/blob/ddfa2cd332887d2af31b50b4edd5759980b8380d/Source/UIComponents/CtrlrPropertyEditors/CtrlrPropertyComponent.h#L301

With it, you'll be able to get the properties of the ctrlrPanel tree via : owner.getProperty(<#const Identifier &name#>);

Try to keep everything happening from CtrlrPropertyComponent instead of having your popup do the job at first.
Let me know if you get results with one of those tips ! Good luck ;-)

[Ted-juh]

Thank you for your suggestions and weeding through the files. Every suggestion is welcome. I'm close to my goal indeed and it's very frustrating to hit a roadblock like this.

I must have deleted too much because there have been multiple CtrlrPanel *owner/ CtrlrPanel &panel declared in the private section. Almost every possible combination possible, if you ask me.

I'll keep this branch to work on this solution, added as options in the propertycomponent. I'll be adding another branch that will do it through an option from the menubar. That's close to completion but hitting the same roadblock for now.

[Ted-juh]

Once I worked my way through deprecated scopedpointers, I now have a fully functional menuItem named Batch which shows a dropdownmenu to choose "Build script editor". That opens kind of the same window like the one in a picture from a post earlier.

The rest should be a walk in the park (cough). I decided to not use a property panel inside the Build script window, just normal text buttons and labels which should be easy to fetch/ retrieve.

I realised later on that I still need access to the panel that is in use at that moment, or at least some parameters but that's for later concern. First get the basics done.

[unityconstruct]

Some unsolicited musings:

Clues for CompileTime success, but RunTime throws error (for process of elimination):

• CompileTime Error denotes semantic coherence
• RunTime Error denotes:
  • null reference being passed or accessed
  • or multiple objects of same type/name exist & a call that looks correct is accessing a null object, or one that isn't initialized
    • two main ways this arises
      • Static/Instance objects exist: when a static object exists & a instance object is created of same Type/Name
      • Scope/Accessibility: Public/Private objects exist: two objects of same Type/Name exist, but within different Scopes
    • The above two conditions would NOT induce CompileTime failure b/c they are syntactically correct - and would only arise once objects are created at RunTime, and/or when access is attempted
      • Was assuming no IDE is available to run in Debug Mode where better tools exist to examine memory at Runtime
        • Thus SnifferSnippet proffered to provide insight to what exists in memory & probe around at 'RunTime' if VisualStudio Debugger not available - though no clue on what objects need to be traversed & may not yield enough visibility to be of use
• These types of problems can be extremely elusive, even with an IDE debugger, so troubleshooting involves a process of commenting stuff out, rebuild, retest to get more clues to wtf.
• The spaghetti mess between *.h & *.cpp lends itself to these types of conditions as it's hard to tell what's being called, if objects being passed are the correct ones .... and the shear number of classes being extended in those constructors adds to the fun

Multiple Constructors:

• Can provide multiple entry points into a class
  • Runtime errors can denote that unexpected Constructor used
  • In this case the logic is incorrect, in that it is using wrong constructor

Debugger

• @damiensellier : Debugging would entail hovering over Constructor Arguments and objects involved with the Crash
  • Setting breakpoints right before the onClick() would allow mouse hover, locals, watches to be set to look for nulls
  • minimally, VS will catch the exception, provide a description ( that may or may not be of much use ), and a context menu containing values
    

API Calls

• API methods/fields may be visible at RunTime, but protected... and improper access can induce Exception Thrown
• JUCE makes mention of this, but may have zero to do with the situation
  

Triage

• Comment out zero-argument constructors

• Comment out all but one constructor

• Add try/catch around that button click

  • really want to use this to write logging to Console Window, but need to update project for two things:
    • CMAKE Debug, not Release
    • Set project to console application

• try catch statement is easy enough, but looked like there were differing debug statements based on type of application

  • debug output useless in Release mode and without a console window

  • even without console window & in Release mode, the Exception Thrown may be superfluous and try/catch will catch Exception and release it
    • might put things in a bad state, but if Error doesn't relate to the goal at hand ( like an unnecessary callback puking ) often times, it can get you on your way.

Try/catch

	if (!authorEmail.isEmpty())
	{
        try
        {
		addAndMakeVisible(labelAuthorEmail = new Label("new label", TRANS("Contact")));
		labelAuthorEmail->setFont(Font(24.00f, Font::plain));
		labelAuthorEmail->setJustificationType(Justification::topRight);
		labelAuthorEmail->setEditable(false, false, false);
		labelAuthorEmail->setColour(TextEditor::textColourId, Colours::black);
		labelAuthorEmail->setColour(TextEditor::backgroundColourId, Colour(0x00000000));
        } 
        catch (const std::exception& e)
        {
            // Debug Output
            // CMAKE Debug, instead of Release to enable debug output
            // Also need set Application to Console Application to enable the Console to be instantiated
            String message = L"DEBUG: if (!authorEmail.isEmpty())\n" + labelAuthorEmail->getName() ;
            std::cerr << message;
        }
	}

Build changes

• migrating off VS build might introduce idiosyncrasies that are nearly impossible to triage.
• removing tags might also cause unhealthy build, so might recommend adding all that junk back in until the feature is working, then go back and hack out things to reduce number of possible root causes.