When a tag is defined for an app designer slider, the value-changing-function for that slider is not triggered.

I'm using Version R2024a. When I create a slider component in App Designer and define a ValueChangingFcn for it, it works fine ... as long as "Tag" (in the "Identifiers" section of the slider) has not been defined. That is, the ValueChangingFcn callback is called as I drag the slider. However, if I define Tag (e.g. 'abc' without the quotes), then the ValueChangingFcn is no longer called when I drag the slider.

I should mention that this appears to occur only with the slider. With a Numeric Edit Field, the presence of a tag has no adverse effect on the call to its callback.

Does anyone know a workaround?

[Stephen23]

"When a tag is defined for an app designer slider, the value-changing-function for that slider is not triggered."

I tried it just now on R2024b, it worked exactly as expected. The app I just created to test this is attached.

[Sherman Marcus]

Thanks Stephen23. You are entirely correct. When I programmed the slider in a new app from scratch, it did indeed work as expected. So my general conclusion was hasty. Now I have to figure out why it does happen in my app, even for newly inserted sliders. Unfortunately, my code is too large to "start from scratch".

[dpb]

Have you checked for any updates for your installation? Which OS and updates for it? Added any new apps to the system?

Does the symptom appear for all sliders or only one?

Does the existing slider then trigger if you clear the 'Tag' property?

Does the problem reoccur if you delete the slider(s) and recreate them?

If the symptom does not go away if you delete all sliders and recreate them and since you note it did not appear in a new app, it would appear something has corrupted the particular project and you may have no recourse but to recreate it unless you have an earlier save version from before the time the symptom appeared that you can use as a starting point.

If it doesn't go away and you can't recreate, the only alternatives I see would be to

1. Don't use the 'tag' property on the affected slider(s), or
2. Use 'UserData' in lieu of 'Tag', presuming that also doesn't cause the symptom

I would also suggest you could attach the .mlapp file to the forum and others could then see if the symptom is reproducible on other installations.

If none of the above resolve the issue, then submit an official support request...

[Steven Lord]

Can you show us the value of the ValueChangingFcn property of that slider before and after setting a value for the Tag property? I want to check that App Designer isn't trying to automatically update the value of the property to reflect the new Tag (if the name matches the default pattern that App Designer uses for that callback function) and so changing it to refer to a non-existent function.

[Sherman Marcus]

Starting with dpb's comments: I'm using Windows 10. The symptoms appear for all sliders in this app. In any slider in this app, if I clear the tag property, it works fine. It happens for existing and for new sliders placed in the app. My app is quite extensive (over 10,000 lines of code so far), so I had hoped not to have to start from scratch. The reason I was using the tag property is that I have 10 sliders and wanted to use the same callback for each. I wanted to use the tag to identify to the callback which of the sliders is being manipulated. Meanwhile, I placed a number on the tooltip of each to identify it to the callback, so I have a workaround.

Regarding Steven Lord's comment: Before setting the tag property, the name of the callback is incWaveSliderValueChanging. After setting the tag property, the name of the callback is still incWaveSliderValueChanging. (Or am I missing something?)

I SO appreciate your help!

[Walter Roberson]

However, if I define Tag (e.g. 'abc' without the quotes)

I am concerned about that "without the quotes" part. Tags must be character vectors or string scalars. Unless you previously defined a variable as a character vector or string scalar, the Tag property would have to be set with apostrophes or double-quotes.

[dpb]

I'll leave you in @Steven Lord's more than capable hands...I just built a two-component app to check; I have not built enough complicated-enough apps to have tried the single callback but I'm flabbergasted that the callback info does not identify the object that initiated the callback in either the app nor in the event structs other than by the subterfuge of having to match the 'Tag' property; I would have thought the object name itself would be there; it has to be known internally. That seems a big oversight/hole...

If @Steven Lord/Mathworks can't find a fix inside the existing .mlapp file using 'Tag', my thinking regarding the problem of starting with a clean app was that you don't just delete everything and start completely over but save all the code in another backup file and then can reinsert in rather than rewriting it.

The question would be at point in creating the UI/callbacks does it break again or is it clean the second go? Of course, if the workaround works, while klunky, "when in Rome...".

Good luck...

[Stephen23]

"I am concerned about that "without the quotes" part."

The OP wrote "When I create a slider component in App Designer.."

When using App Designer the text is entered without quotes:

App Designer converts this to a character vector and sets the Tag property with it.

[Sherman Marcus]

Indeed, I had thought of the possibility that Steven Lord mentioned and tried 'abc', but it threw an error. Besides, when I start from scratch and my callback IS triggered with a defined tag, that tag is abc without quotes. Furthermore, with my current code, I use tags in a callback to identify which of a series of numerical text boxes I change the value of, and it works just fine. Only the slider is problematic in my app.

I certainly agree with dpb that it would be great if the Event parameter in the callback would include the name of the caller, since it already contains the tag and the tooltip of the caller.

[dpb]

Keep us posted if Mathworks comes up with a solution either here presuming @Steven Lord does continue to follow up--I would give that a while but if nothing happens, I still think this would be worthy of an official bug report

[Sherman Marcus]

Before I throw in the towel, I thought of a couple of other facts which might provide a hint to someone. (1) When the tag property is set, the valueChangingFcn is not triggered, BUT the valueChangedFcn IS triggered (if defined). (2) My code was converted many moons ago from GUIDE using the Guide-to-App converter, and I have continued development since then using App Designer.

I thought this might be significant since some of my original GUIDE sliders are still in the code with the Tag property set, and those still work. I just realized that the reason they work is that they use the valueChangedFcn since in GUIDE there was no valueChangingFcn. Is it possible, then, that something was carried over from GUIDE that would cause the valueChangingFcn not to work when the Tag property is set?

[dpb]

That is interesting observation and indeed undoubtedly there's something related somehow; those symptoms would seem to imply the conversion still leaves links to older code left over from GUIDE days despite all the visible user source code being in the new app designer interface.

I would think this would be of interest to Mathworks; I wonder if it is intended or an artifact of the translation that isn't doing what is expected. Or, maybe there's stuff buried so deep behind the scenes it simply isn't possible for the conversion app to be able to fix.

Does your UI rely on the 'Changing' callback to do something different than from the 'Changed' callback?

[Sherman Marcus]

My UI definitely takes advantage of 'changing' rather than 'changed'. When 'changing', I can show the effects while moving the pointer, thereby providing ongoing insight into the various physical phenomena. As a matter of fact, even in GUIDE, I recall I used some "listener" function to provide that same 'changing' effect.