# Tips to move from functional programming to GUI-based applications

Even though this forum has some questions related to Mathematica programming tips I think that we still don't have specific help for those who want to learn to efficiently create GUIs in Mathematica. Indeed, I think that the capabilities of the Wolfram Language for building applications are often underestimated because many good developers have not yet developed the best skills to create GUIs in Mathematica. The argument "Mathamatica is not for that" is often offered as an answer that misleads those who are trying to create applications in Mathematica. Mastering Dynamic or adding the option Method->"Queued" to buttons are part of the story but there are many other issues that need to be understood. Example questions are:

• When to use DynamicModule instead of Manipulate?
• How to create an efficient DynamicModule?
• When to avoid using DynamicModule or Manipulate?
• How to effectively use functions instead of variables to create GUIs?
• Where to place Dynamic?
• When should TrackedSymbols be used and which symbols should be tracked?
• When and how to use SynchronousUpdating?
• How to avoid the message Formatting notebook contents?

It has taken me a lot of time and energies to learn the answer to most of these questions (examples in my profile) but I would like to help others by posting the following question. Can this forum provide a list of practical tips, suggestions or examples to learn creating efficient GUIs in Mathematica?

• related: Guidelines for planning custom GUI in Mathematica. p.s. Great question +1
– Kuba
May 12, 2016 at 17:59
• Could you explain 4th point further?
– Kuba
May 12, 2016 at 18:03
• @Kuba: Maybe 4th point is a personal programming style I've come to develop while creating applications. It may take more than the space I have in a comment to explain but the main point is to use varName[k] instead of varName such that k can be used for storage and quick and easy access to a set of pre-computed GUI components which will be called and used as the user clicks to generate different GUI states. varName[] also has DownValues and that may play an important role in some applications. May 12, 2016 at 18:21
• I think it is a great idea to pose these questions (and to self-answer if you have the answers). However, I think I would prefer to see individual questions instead of one "big list" question (plus, you'll get more rep for the multiple questions and answers). For example, a question for the 4th point would frame that particular problem and then be self-answered using functions instead of variables. May 12, 2016 at 20:14
• @WReach The problem I have with individual questions is that they may need to share a common context, which in that case will have to be reintroduced as many times. In the present setting, one can write one generic answer and link to other answers on the same page, addressing specific bullet points. Besides, some carefully chosen examples may answer or illustrate several points at once, and it would be harder to do if different points would live in different pages - while for a single page, such examples could be posted in the "common" answer. May 12, 2016 at 20:33

## Dynamic inside Manipulate

A tip that I would like to contribute is to use Dynamic with controls such as sliders, checkboxes and input fields inside Manipulate.

This enables one to place the control anywhere (even inside a figure) and to tie controls together.

Imagine a Manipulate with several controls where you like everything except ... you would like to place one control in a non-supported place and/or would like a non-supported relationship between two control variables. This is a case where Dynamic might prove useful.

I typically initialize the controls by placing them in the normal spot for Manipulate but setting the control type to None.

Below is a toy example where I want to have a slider that has a logarithmic spacing but have the value print normally. It actually has a practical application for various NMR (Nuclear Magnetic Resonance) GUI's that I built.

Changing the input field (t2xfw) will cause a *simultaneous change in lt2xfw once Enter has been pressed.

The slider is an example of sequential change. Dynamic will accept two functions in a list. The first function occurs when the the slider is moved and the second when one releases the mouse (i.e., t2xfw doesn't change until the mouse is released).

Manipulate[
Grid[{
{"Log T2", "T2"},
{Round[lt2xfw, 0.001], t2xfw}
}, Frame -> All],

(* Controls *)

{{lt2xfw, Log[0.1]}, ControlType -> None},
{{t2xfw, 0.1}, ControlType -> None},

Grid[{
{
"T2 ",
Manipulator[
Dynamic[lt2xfw,
{(lt2xfw = #) &, (t2xfw = Round[Exp[lt2xfw], 0.00001]) &}],
{Log[0.001], Log[9.0]}
],
Spacer[2],
InputField[
Dynamic[t2xfw,
((t2xfw = Round[#, 0.00001]; lt2xfw = Log[t2xfw]) &)],
Appearance -> Frameless, FieldSize -> 4]
}
}]
]


• @JackLaVigne I may be missing your objective, but to me your code is in the thresholds of the unnecessary use of Manipulate. You can easily create a DynamicModule[{lt2xfw = Log[0.1], t2xfw = 0.1}, ... version of your example wrapping the calculations with Dynamic. The only missing component would be the [+] controls that Manipulate offers which maybe you won't use. The downside of using Manipulate is an additional invisible Dynamic wrapper to your code which in a more complicated example may trigger many unnecessary updates. Why use Manipulate if you are creating the controls manually? May 18, 2016 at 17:47
• For the given example the same control placement can be achieved with less redundancy using Control. See: i.stack.imgur.com/06AKH.png. Unfortunately the syntax highlighting seems to be broken for this. May 18, 2016 at 17:55
• @ArielSepulveda Manipulate has value in the ease of creating GUI's. Visualize a Manipulate with several controls where you like everything except ... you would like to place one control in a non-supported place and/or would like a non-supported relationship between say control variables. For these cases using a control with a Dynamic inside Manipulate may just be what the doctor ordered. May 18, 2016 at 20:37
• @JackLaVigne Yes you are right. I used the word threshold because I've seen many cases where people push Manipulate too far and end up creating inefficient and lengthy code trying to adapt Manipulate instead of creating a real simple solution. I think that Manipulate is great for what is was designed (classroom type of examples) but is usually not good at all for most real-life applications. May 18, 2016 at 21:32

I tend to do manipulate for lightweight applications because it will auto refresh and I think it looks better. The auto refresh also helps with the user interface because I think it's more intuitive than having to press enter or even a button.

Dynamic may be a better choice for applications where the user would want to set multiple parameters to a specific value before executing, and also situations where lagging would be so significant that it would be frustrating to the user.

I'm sure there are workarounds in both cases. I'll leave it to the more experienced users to give a more comprehensive answer.

It may be worth noting as well that Manipulate GUIs seem to be far easier to write.