GUI Callback

I have a question about using editable text fields and push buttons.

I am new to coding GUIs and am having trouble creating one for a Fortran program I wrote. I would like to make a GUI that takes user inputs through editable text fields and saves these values to a file (.txt., .dat. or .mat, whichever is best for Fortran). I am having trouble saving my data, as it seems that the strings from the text fields aren't saved to the workspace, so when I set the pushbutton callback, it does not find the string values from the text fields For example,

Bz_eth = uicontrol(fh, 'Style', 'edit', 'Position', [40 130 130 20]);

pbh = uicontrol(fh, 'Style', 'pushbutton', 'String', 'Run', 'Position', [525 20 50 25]);

set(pbh,'Callback','save data.txt get(Bz_eth,''String'') -ascii')

I have tried several other ways (unsuccessfully), such as writing a subfunction to save the data to the workspace and then using it in the callback, but the data isn't saved and the subfunction instead saves empty arrays (as the text fields are empty when the GUI starts). Any suggestions on how to fix my code or how to implement it better? I truly appreciate your time. Thank you

Answer 1

[Walter Roberson]

When you use a string as a Callback, the string is executed in the base workspace, not in the workspace of the function that set the callback.

Also, you are trying to mix command line syntax and function syntax in your save command.

set(pbh,'Callback',@(src,evt) save('data'.txt', get(Bz_eth, 'String'), '-ascii') );

[Cesar Huerta]

Now it's taking the string from the text field and treating it as the name of a variable. I want the string to be an actual value, like 50 or 17 or something. Can I first save these values into variables and then export them to a text file using the set statement you have above?

[Walter Roberson]

You cannot save a particular numeric (or string) value directly by using "save". You have to create a variable with that value and save the variable instead.

You are probably going to find it easier to construct a real function for this purpose rather than an anonymous function.

Do not forget to convert the string to numeric before saving the value.

Answer 2

[Image Analyst]

Any reason you're not using GUIDE, where you wouldn't have that problem? With GUIDE, each callback function has access to the handles structure, from which you can get the value, contents, or selected item of any/all of the controls on your GUI. No need to worry that the callback won't have access to one of your handles, and so can't get or set its properties, like you're experiencing now.

[Walter Roberson]

No need to worry? Hmmm. http://www.mathworks.com/matlabcentral/answers/41858-variables-in-guide-program-mysteriously-being-reset

[Cesar Huerta]

The only reason I'm doing this by hand is that it's for a research project and I wanted to really learn how to code a GUI; I feel like using GUIDE is like cheating

[Image Analyst]

If you feel like it's cheating, then go ahead and do it the hard way. But virtually no professional programmers start from the lowest levels. Do you know anyone who uses Visual Studio who does that? No - they all use the dialog box editors (though it is far far superior to GUIDE). And you'll just be wasting time (which means money) reinventing the wheel when it comes to coding up all the functions in some toolbox because using them would be cheating. And God help you if you ever need to write your own compiler because it would be cheating to use the built in compiler. In fact, maybe you should consider using MATLAB at all "cheating" because it does a lot of stuff for you. Why don't you just write everything in C or Java? I most likely would not hire a person if I found out that they wanted to build everything themselves and not take advantage of tools that can make their life simpler, get projects done faster, and make them a more productive employee. Sorry if this sounds harsh, but for your own good I really really suggest you get over that feeling so you can use built in capabilities and become more productive.

[Cesar Huerta]

Hey man, relax a little, I didn't mean to offend you. I just meant that I felt like I wouldn't learn as much if I used GUIDE. Sure, I would get the GUI I want, but if I wanted to do something on my own I wouldn't know how to go about doing it. I feel like starting from the very bottom gives me a better foundation so I understand what my GUI is doing

[Walter Roberson]

"The perfect is the enemy of the good" -- Voltaire.

"Good is the enemy of great" -- Jim Collins

"good and bad coin cannot circulate together" -- Sir Thomas Gresham

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." - George Bernard Shaw

GUIDE is "good enough" for a number of things, but has many limitations, and it promotes use models of MATLAB GUI frozen in time; and it does not not encourage people to learn the more advanced capabilities (indeed, it tends to lull people into thinking that what GUIDE provides is all that is possible.)

GUIDE might be good enough for cases where the user experience is not a serious consideration, for research cases where the research algorithm is the only really important thing, and the user interfaces are just useful ways to trigger the research algorithm. But in a competitive environment, when the technological capabilities and price are roughly comparable, people select the choice with the better user interface.

Image Analyst works in a fairly specific field, image processing research, and pretty much only in that field. Adopting GUIDE is perhaps appropriate for his circumstances.

I work in a wide variety of fields, not a niche. I use the tools appropriate for the circumstances I am working in. GUIDE is often inappropriate for what I do. Knowing what is actually possible and the tradeoffs involved is what is appropriate for what I do.

Every sufficiently large organization needs someone who can look at how the program runs, see a flaw, and trace it back through the code, trace back through the tool that produced the code, and trace right back through the compiler that produced the tool, and say "This is wrong, and here's how to fix it." Those people get to where they do by studying how things *really* work.