I have changed the "Product" label on your Question from Maple 2018 to Maple 18, since the latter is the version in which your attachments were last saved.

Maple 18 was released in the year 2014, and is four major releases old than Maple 2018.

I have deleted your duplicate Post in which you complain, without example, of the quality of the Maple GUI.

I deleted it because it is no more than a duplicate of this Post.

If you have additional details of your issues and frustrations, then post them here.

Are you using 2D Input mode, in a Document, which is the default for new users the GUI?

If so, have you tried 1D Input (plaintext "Maple Notation") mode, in a Worksheet?

Those can be set as preferences under Tools->Options in the GUI's main menubar. That is,
  1) Tools->Options->Display and toggle the "Input display" combobox entry to "Maple Notation".
  2) Tools->Options->Interface and toggle "Default format for new worksheets" to "Worksheet"

I am just guessing here. Copying input code can be problematic in 2D Input mode, since the GUI's editing facility insists it knows better and can offer only copying what it thinks are parsable portions of a larger 2D Input block. In 1D Input mode it is much more amenable to sub-selecting and copying -- ie. it allows pretty much any subselection from a block of plaintext code.

If you prefer plaintext coding, you could also utilize so-called Code-Edit Regions within a Document. But if you also have issues with Document navigation then 1D Input + Worksheet may be preferable.

The more specifics you can provide about your code editing issues the more we might be able to help.

@Scot Gould I find type realcons to be useful, because it should allow you to know that you can hit the scalar value with evalf and obtain a float.

For example,

type( sqrt(2), realcons );
              true
type( Pi, realcons );
              true

@DoingMath2018 The unevaluation quotes merely delay evaluation, and the quoted expression is not inert. Each full evaluation will strip off a set of uneval quotes. Strip off them all, and you get your original error. It's fragile because several common things induce an evaluation (eg. passing in as argument to a procedure call).

That's why I gave my second example, using %plot to obtain an inert form. The call to %plot can be evaluated, multiple times, without that same problem. When you're ready to produce the actual plot -- following substitutions and manipulations, etc -- then you can utilize the value command on it.

@Scot Gould Yes, failing to hit the upper end-point (due to roundoff error making the last value exceed the bounds) is somewhat understandable. But missing two values is odd.

By the way, I submitted a request this past year for an enhancment to seq. Instead of supplying the float increment as an option I asked to be able to supply the number of values. Eg,
   seq(a..b, number=4);     # or similar syntax
The idea is twofold: 1) To avoid roundoff issues and always hit both end-points, and 2) To avoid fencepost mistakes such as accidentally dividing b-a by N or N+1 instead of N-1, etc.

@DoingMath2018 His 3rd example is in the same vein as my first, using unevaluation (single right-quotes) to delay evalution.

There are many common scenarios in which such a quoted expression gets accidentally evaluated. For example, by passing it around as argument to some procedure call. It can be a somewhat fragile mechanism.

But even if you do not intend on passing the unevaluated call, there are still more graceful mechanisms.

For example, using a procedure.

Or substituting into the arguments of the plot call rather than into an unevaluated plot call. I think that the first of these is less contrived than the second.
  plot(x, eval(x = 0 .. a, [a=3]));
  eval('plot(x, x = 0 .. a)', [a=3]);

@Scot Gould I'm sorry, but I don't understand your comment.

I use ':-size' to try and protect against the case that the user might have assigned some irrelevant value to the global name.

I'm not sure what you are saying about images and global sections.

Note that so-called plot persistence can sometimes have an effect -- if you get rid of a plot's size option then the GUI remembers the old dimensions used to render in that output area. If a new size is not explicitly provided then it can happen that the GUI re-uses the old dimensions. Removing the old output, first, then displaying the new, gets rid of that effect. I'm not sure if you ran into this behavior, but it can be confusing when trying to figure things out.

There is no attachment.

@sunit It's easy enough to make a reusable procedure for it.

You can apply it to each equation, or to a system (set) of them.

question_sunit_ac2.mw

By the way, if you were to go with Kitonum's suggestion to convert to rational, then in general it would be better to substitute using convert(par,rational,exact) instead. (Don't incur possible roundoff error in general, if you don't have to.) I didn't show that way because it produces a result with rationals instead of the short floats, so it doesn't answer the question you actually asked.

@eslamelidy You can use the plots:-display command to combine plots.

x_e_-.008_2_ac.mw

@emendes You could somewhat reasonably extended your catch to , say,

   catch "time expired","does not exist","invalid input","at offset":

You could also insert another catch clause (a try..catch can have several, which are checked in succession). It is sometimes useful to put in, as a final catch clause, a plain,

   catch:

to trap any remaining errors.

Then you may deal with that as you see fit. You could print something or take some suitable computational action, then optionally rethrow an equivalent error message using the error statement.

See also the use of the StringTools:-FormatMessage command, and lastexception, in an Example on the ?error Help page. This is sometimes useful, for re-throwing a message, turning an error into a warning, or what have you.

What I meant about flags is that in some complicated situations the preliminary actions done within the try clause (prior to an error) might change the state of some variables, etc. You might have a situation in which you need to reset certain things in a finally clause, and so it can help to record the initial status or successes at earlier stages.

Breaking up a try..end try with an overly involved try clause into smaller steps can sometimes help, if it becomes unwieldy.

@Carl Love Something like this?

Download genglobal_ac3.mw

@nm Ok, you did not state in the original question that you wanted repeat calls to utilize the same dummy name. But as I mentioned, it could be accomodated.

Do you want different ode problems involving the same third argument to utilize the same new name? I'll guess that is so, too.

Download genglobal_ac2.mw

It's always better to describe as much about your requirements as you can up front.

@Ali Hassani Please keep this discussion centralized, instead of spawning off an unconnected new Question thread.