Please, accept my current pull request, which contains modifications in DXLookNFeel.cpp.
In comparison the related part of its former PR there are the following differences:
1) Because the dexed-pipeline failed yesterday in the case of build-macos due to the deprecation of forEachXmlChildElementWithTagName(), I have replaced it by for-loop based on juce::XmlElement::getFirstChildElement() as initialization and juce::XmlElement::getFirstChildElement() as iteration.
2) I have introduced a method replaceImage() instead of the findImage(). Its reason is that findImage() returns nullptr in that case when DexedTheme.xml refers to a nonexistent image (or the loading of the given image is failed by some other reason). At this point, nullptr will be stored in the corresponding image variable, which results in nothing being displayed on the screen instead of the associated component. For instance, if we specify a broken path in the DexedTheme.xml for the Light_28x28.png˛, e.g.
<image id="Light_28x28.png" path="nonExsitentSubdirectory/Or/MissingPicture.png"/>
then all the LEDs disappear from the GUI:
despite that the proper image variable was initialized to the image of a red LED before.
The new method replaceImage() updates the image variable with the new image only if the loading of the new image was successful. So, when a nonexistent image is specified in DexedTheme.xml, the original content of the proper image variable
will not be overwritten, so the default red LEDs are displayed:
Or, if the new image file exists, e.g. GreenLight_28x28.png in the relative path myTheme/, and was loaded successfully due to line
<image id="Light_28x28.png" path="myTheme/GreenLight_28x28.png"/>
in DexedTheme.xml, then its content (green color LED, in this example) are displayed:
Thank you in advance! (hoping that all the checks will be passed now...)
Dear Pascal,
Please, accept my current pull request, which contains modifications in
DXLookNFeel.cpp.In comparison the related part of its former PR there are the following differences: 1) Because the dexed-pipeline failed yesterday in the case of
despite that the proper image variable was initialized to the image of a red LED before.
build-macosdue to the deprecation offorEachXmlChildElementWithTagName(), I have replaced it byfor-loop based onjuce::XmlElement::getFirstChildElement()as initialization andjuce::XmlElement::getFirstChildElement()as iteration. 2) I have introduced a methodreplaceImage()instead of thefindImage(). Its reason is thatfindImage()returnsnullptrin that case whenDexedTheme.xmlrefers to a nonexistent image (or the loading of the given image is failed by some other reason). At this point,nullptrwill be stored in the corresponding image variable, which results in nothing being displayed on the screen instead of the associated component. For instance, if we specify a broken path in theDexedTheme.xmlfor theLight_28x28.png˛, e.g. <image id="Light_28x28.png" path="nonExsitentSubdirectory/Or/MissingPicture.png"/> then all the LEDs disappear from the GUI:The new method
Or, if the new image file exists, e.g. 
Thank you in advance! (hoping that all the checks will be passed now...)
replaceImage()updates the image variable with the new image only if the loading of the new image was successful. So, when a nonexistent image is specified inDexedTheme.xml, the original content of the proper image variable will not be overwritten, so the default red LEDs are displayed:GreenLight_28x28.pngin the relative pathmyTheme/, and was loaded successfully due to line <image id="Light_28x28.png" path="myTheme/GreenLight_28x28.png"/> inDexedTheme.xml, then its content (green color LED, in this example) are displayed: