How can i enter the input in MATLAB GUI ?

Hello Everyone,

I'm trying to design a gui. In GUI, MATLAB will give random 5 characters and user will enter the same 5 characters. How can i enter the input in MATLAB ? I used Edit Text but it won't work.

[Adam]

Edit text should work fine, but if you don't show any code or elaborate on what the vague 'won't work' means there's not a whole lot else to say!

[Yusuf Oguzhan Turgut]

allNumbers=0;

SymbolsShift={'"' '!' char(39) '^' '+' '%' '&' '/' '(' ')' '=' '?' '_'};
SymbolsAltGr={'@' '#' '$' '{' '[' ']' '}' char(92)};
SymbolsNormal={'*' '-'} ;
SymbolsDown={'<' '>' '.' ':' '|'};
SymbolsNumber={'1' '2' '3' '4' '5' '6' '7' '8' '9' '0'};

if allNumbers==1
    allSymbols=[SymbolsNumber];
else
    allSymbols=[SymbolsShift SymbolsAltGr SymbolsNormal SymbolsDown];
end

alpha1=0.7;
alpha2=0.3;
M=5;
%N=100;
N=15;
CorrectlyTyped=0;
tic
k=0;

actualCell=allSymbols([floor(length(allSymbols)*rand(M,1))+1]);
% % % %     actualCell={char(92) char(92) char(39) char(39) char(92)};
    actualMat=cell2mat(actualCell);
    backSlashes=find(actualMat==char(92));
    kk=1;
    forScreen = [];
    for jj=1:M
        if ismember(jj,backSlashes)
            forScreen(kk:kk+1)='\\';
            kk=kk+2;
        else
            forScreen(kk)=actualMat(jj);
            kk=kk+1;
        end
    end
   set(handles.q1,'String', char(forScreen(1)));          
   set(handles.q2,'String', char(forScreen(2)));
   set(handles.q3,'String', char(forScreen(3)));
   set(handles.q4,'String', char(forScreen(4)));
   set(handles.q5,'String', char(forScreen(5)));

This code will give random character to the output. However, User will enter the same characters. And GUI will check the size first, after that it will display in another blank. I cannot do that.

[Rik]

How should the user be entering characters?

And please use the layout tools when posting a comment.

[Jan]

@Yusuf: "I used Edit Text but it won't work." - please mention any details about the problem. " I cannot do that" does not reveal also, what the actual problem is.

By the way, a simplification:

actualCell = allSymbols(randi([1, numel(allSymbols)], M, 1);
% I do not understand, why you replace \ by \\, but this is easier:
forScreen  = strrep(actualCell, char(92), '\\');
set(handles.q1, 'String', forScreen{1});          
set(handles.q2, 'String', forScreen{2});
set(handles.q3, 'String', forScreen{3});
set(handles.q4, 'String', forScreen{4});
set(handles.q5, 'String', forScreen{5});

Answer 1

[Murugan C]

Hi Yusuf, I have created simple layout for your queris. I hope this attached gui files should resolve your issue. If it is not, please post your full code or attach your files.

[Rik]

You shouldn't be using GUIDE. Once you move beyond an extremely basic GUI it becomes really hard to understand and maintain.

My small guide to avoid GUIDE:

• Make a figure (with f=figure;) and look into the doc for figure which properties you want to turn off (you probably want to set Menu and Toolbar to 'none')
• Create buttons and axes and everything you need with functions like uicontrol and axes. Save the handles to each element to fields of a struct (like handles.mybutton=uicontrol(___);)
• When you've finished loading all data (and saving it to fields of your handles struct), and creating all the buttons, save your handles struct to the guidata of your figure like this guidata(handles.f,handles);. (You can also use getappdata and setappdata)
• You can set the Callback property of many objects. If you do, use a function name with an @ in front, or a char array that can be evaluated to valid code. (like @MyFunction or 'disp(''you pushed the button'')')
• Callback functions will be called with two arguments: the first is a handle to the callback object, the second is eventdata that may contain special information. To get access to your data, just use handles=guidata(gcbo);. You can replace the gcbo function with the name of the first input to your callback function if you prefer.
• More information about callbacks can be found in multiple places in the doc, for example here.

[Murugan C]

Hi Rik, I knew that how to create gui without using GUIDE. My suggestion would be, GUIDE will be easy and simple to create gui appliacation even user doesn't know about @MyFunction etc..

[Rik]

These are not very advanced Matlab things. GUIDE has held me back from making GUIs for several years. If you want to advocate for a tool people should be using, you should advocate for AppDesigner. GUIDE has seen little or no changes over the pased years. Did you notice it still uses the function-without-end-keyword syntax? Did you also notice the auto-generated help text describes the eventdata as reserved for use in a later release? That 'later release' dates back to the early 2000s...

Mathworks itself is suggesting not to use GUIDE, so why teach it to new users as a black box? Black boxes are sometimes necessary, but they are a bad idea if your sole reason is to not intimidate new users. If a new user is intimidated by a function handle, they should be mortified by GUIDE.

Another consideration is that .fig content might not be compatible with all releases, so even this turn-key solution might not work for everyone. Code is a lot easier to make compatible with multiple releases. I'm not suggesting you should go as overboard as I'm doing, but why would you introduce a potential bottleneck if you don't need to? (most, if not all, of my GUIs are compatible with every release from ML6.5 to the current release, and with GNU Octave, try doing that with a fig...)

[Adam]

The sad thing is GUIDE is still far better than App designer for creating a lot of GUIs, even if it hasn't seen development for 10 years. I don't think people in an Answers forum should really be giving strong objections to not use any of the app-building approaches though. All have their uses. For a very simple UI from scratch GUIDE is still a very quick way to put a UI together. There are plenty of pitfalls to it, but it isn't difficult to get right without falling into them and both app designer and programmatic UIs also have pitfalls, especially for someone new to GUI design.

App Designer's use of classes makes it potentially far more versatile if/when it evolves to no do all the things that would be expected of a GUI builder. It matches far more closely than GUIDE to how I build programmatic apps using OOP, but it is still a very obvious work in progress.

It's certainly true that GUIDE is being phased out and is no longer recommended by Mathworks, but the relevance of that depends a lot on the expected lifetime of your GUI.

[Rik]

My main objections to GUIDE are the bloated comments, the strange way it starts, and the convoluted method of running the callbacks. Those are fairly superficial things to object to, but they are difficult to understand for new users. I think it is sad how GUIDE is being dumped, because it really has a lot of potetial.

Maybe I'm weird, but I don't like the idea of use-once-and-trow-away GUIs. They have a tendency to stick around and cause a lot of headaches for future maintainers.

I really like the division that would be possible here: class-based or function-based. Either has their optimal use cases. My main point is that GUIDE is not properly fulfilling the role of the function-based designer because its limitations.

I don't agree that this forum is not a place to give strong advice over an approach. I don't think anyone objects to discouraging the use of eval. I don't think GUIDE reaches that level, but I do believe it is more of a hindrance than a help to users who are new to GUI design.

[Adam]

I agree that giving opinions about a best approach is good, I just think statements as strong as 'You shouldn't be using GUIDE' imply that the user is doing something fundamentally wrong rather than just something that may be considered to not be the best way to create a GUI.

It's certainly good to give a guide to creating a programmatic UI, but it is easy to overestimate how easy it is for a new user to follow when you are so used to doing it yourself. For example, the biggest issue I always have with programmatic GUIs is positioning the components - having to give exact positions for every component you add is not a trivial task. So much so I never do it and always use the GUI Layout Toolbox and its layouts instead, but they certainly take time to make work correctly.

For a new user creating a GUI having a canvas style place to build your UI by just dragging controls across onto the canvas is quick and intuitive and can be done in a few minutes, depending how the controls are arranged (obviously things like a grid of buttons lend themselves far better to programmatic placement anyway). What comes after that is admittedly questionable, although I am continually surprised by the number of problems people have with GUIDE (though again that is probably because I have used it for over 10 years). It's not intuitive if you don't read a couple of vital help pages, but if you do it is simple.

So then there's app designer. Maybe for people new to GUIs this is the ideal. For me as an experienced GUI designer it has numerous unacceptable flaws, but they are mostly advanced issues (last time I checked) - editor formatting options not matching the main editor, having sections of code uneditable, being unable to name the object itself anything other than 'app', being unable to re-order property or method blocks to my taste, etc, etc. Worst of all, app designer makes all UI components un-editably public properties which I find appalling! These things just make me rage quit when I try to build an app in app designer, but new people not used to building GUIs in fully editable classes maybe wouldn't care.

[Jan]

I prefer to create GUIs programmatically, because then I have full control and the GUIs are working under Matlab 7.0 to 2019a without incompatibilities (with some limitations, e.g. that the graphic handles are not assumed to be doubles and no string classes are used). I keep the actual computations separated from the GUI code to allow for an easier maintenance.

My GUIs get some default parameters from a specific function, e.g. fonts, scaling factors, color schemes and default positions, e.g. the last used position with an automatic reset if a 2nd monitor has been switched off.

For a beginner this method would be an overkill. GUIDE and AppDesigner let you create a GUI much faster and with less groundwork. The drawback of incompatibilities between different Matlab versions and the limited possibilities are less important than. If you want to create one or three GUIs, GUIDE and AppDesigner are efficient. For a professional programmer and for 72 GUIs, these tools are too dull. The differentiation is easy:

How much programming time does it cost until the GUIs do, what you need?

Or in other words: You should use GUIDE, if it solves your problem efficiently, and vice-versa.

[Rik]

Maybe I should write GUIDE2.0 some day, then I could suggest using that for the cases where you want rapid prototyping. Functions like the one you describe for default parameters would be ideal. A function like the one below can also be useful in building a GUI, but they look intimidating really quickly.

But let's be realistic: that is a huge amount of work, so I probably won't actually do it. Maybe if there are other people willing to participate in the effort. I suspect our time is more helpfully spent on this forum than on creating GUIDE2.0.

function fig=blank_figure(varargin)
%Create a blank figure that has no fancy controls or menus.
%
% Inputs are piped to figure(), so all the normal syntaxes are supported.
%
% Creating a figure without bells and whistles is especially useful if you
% want a robust way to generate an image without the possibility of user
% interaction leading to unexpected behavior.
% Another use case is the creation of a GUI, where it is better to manually
% add back any extra controls that the required releases support.
%
% This function is compatible with all Matlab releases

fig=figure(varargin{:});

% To remove the new interactions (introduced in R2018b), we need to use
% some tricks. 
%
% Use eval to trick the syntax checking in ML6.5 (both the ~ and the @ trip
% up the syntax checker).
%
% Using evalc ensures that you can group functions in a single anonymous
% function that otherwise have no output (as neither set() nor
% disableDefaultInteractivity() have output arguments).
persistent defaultAxesCreateFcn
if isempty(defaultAxesCreateFcn)
    defaultAxesCreateFcn=eval(['@(ax,~){',...
        'evalc(''set(ax.Toolbar,''''Visible'''',''''off'''')''),',...
        'evalc(''disableDefaultInteractivity(ax)'')}']);
end
%We only need to modify the creator function on >=R2018b
try %#ok if verLessThan is missing verLessThan would have returned true
    if ~verLessThan('matlab','9.5')
        set(fig,'defaultAxesCreateFcn',  ...
            defaultAxesCreateFcn);
    end
end

%remmove other controls to ensure a blank figure
set(fig,'Menu','none','Toolbar','none');
end