Here's an alternative view. I put as little code as practical in the embedded component, typically a call to a procedure, possibly with an argument that identifies the embedded component. The functionality is contained in the procedure, an export of a module. As an example, a button may contain
while the startup region may contain
_App := SomePackage:
where SomePackage is the name of a module that is saved in a Maple archive (mla). An advantage of this approach is that it's a lot easier to maintain the code. This may be overkill for your usage. A hybrid approach would be to insert the Maple code that defines the module into the startup region.
Followup The OP asked for an example. Here it is: DoubtOnLatestCodesinEmbeddedPlotAlt.mw. I modified his original to use a package assigned in the startup region, and included a call to with so that the package exports, used by the sliders, can be accessed without referring to the package name. While I don't always use with, one advantage to doing so is that the code in the embedded components is then, essentially, inert and error-free until the package is assigned. Otherwise, if MyApp:-ChangeA() was inserted as the code for the A slider, any time the slider was clicked an error would be raised (and raised repeatedly, making it a pain to fix) stating that MyApp was not a module.
For complicated applications, using a single procedure call in an embedded component has a lot of practical advantages. One of them is that it facilitates debugging. For example, in the worksheet you can add and execute the line
then, when you move the A slider, the Maple debugger will be launched and you can step through ChangeA and, if desired, its call to UpdatePlot.