The "Dragged" action code of a PlotComponent is called multiple times while the mouse-pointer is dragged around. (The frequency at which it gets called is not adequately documented.) But that is the main difference between the "Dragged" code and the "Drag end" code which is only executed once per drag, when dragging stops. The "Dragged" code allows you to get a kind of continuous effect, programmatically, as the mouse is dragged around the plot.

Here is a simple example, with comments.

ECPlot_dragged_example.mw

I prefer to make the relevant "action code" property of the Component be just a simple call to a procedure that I define elsewhere. That makes it easier to adjust the code. Eventually such code could be tidily hidden away inside, say, the Startup Code Region of the worksheet.

It's easy to make other fun applications. This second example uses the endx,endy pair as initial value for a phase-portrait of a 2D ode solution, using DEplot. As you drag the mouse-pointer around the resulting solution curve moves through the field-plot. Execute all the code in this attachment, then left-click&drag around the plot...
ECPlot_dragged_DEplot_example.mw
(This example is designed for simplicity, not efficiency. Otherwise I'd call dsolve once up front, and then odeplot in the action code.)

The .mws file from the Application Center loads in Maple 2017.3 with the definitions of id, eq1, and eq2 missing.

I retyped the three missing definitions, by reading the display rendered on the App Center. (Check for mistakes in my transcription.)

I also corrected the faulty calls to plots:-odeplot. (Even the display on the App Center page demonstrates those as being wrong.)

Download half-wave_full-wave_diode_rectifiers_ac_2017.mw

I will submit a bug report against that App Center item.

plots:-textplot({[4.2,1.9,sin(nprintf(`#mn("%a°");`,30))]},
                symbol=point,color=black,
                font=["Arial","Bold",25]);

Naturally, you could also define a reusable procedure for constructing those. Eg,

F:=v->nprintf(`#mn("%a°");`,v):

plots:-textplot({[4.2,1.9,sin(F(30))], [4.2,1.2,sin(F(35.6))]},
                symbol=point,color=black,
                font=["Arial","Bold",25], view=[2..6,0..3]);

seq(F(15*i), i=0..6);

etc.

All the above worked in my Maple 16.02. I suspect it would work in Maple 13. Let us know.

Carl has already explained that your original mistake is using coords=spherical when it was not appropriate to your formulation.

I'd like to make some additional comments, and show one more variant.

In some examples below I will use a slightly different method to generate the lower cap (base disk), simply because some approaches work better according to how the spherical surface is generated. The result is better if there are no visible chinks and holes where light shows through the intersection between the base and hemisphere (upon manual rotation, say).

I often use 3D plots with style=surface (a.k.a. patchnogrid), with the default lighting. But I really dislike any shadow artefacts, which can occur where the surface's parametrization's end-points occur. I'll show what I mean below. The emphasis here is on the visible rendering quality of the spherical portion.

Take this approach similar to what Carl suggested.

H1:=plots:-display(
     plot3d(3,th=0..2*Pi,phi=0..Pi/2,coords=spherical),
     plot3d([r,theta,0],r=0..3,theta=-Pi..Pi,coords=cylindrical) ):
plots:-display(H1, scaling=constrained, orientation=[180,77,170], style=surface);

You can see the vertical seam's shadow, along the surface. That happens whether one uses the parametric calling sequence (as Carl did) or the scalar calling sequence (as I've done here). Increasing the grid resolution doesn't fix this. This is a drawback to this approach.

Now consider this quite natural approach using cartesian coordinates (which the OP has alluded to in a subsequent posting).

HR:=plots:-display(
     plot3d(sqrt(9-y^2-x^2),x=-sqrt(9-y^2)..sqrt(9-y^2),y=-3..3,style=surface),
     plottools:-transform((x,y)->[x,y,0])(plottools:-disk([0,0],3)) ):
plots:-display(HR, scaling=constrained, orientation=[90,77,170], style=surface);

Near the points x=0 and y=+-3 there is a nub on the spherical surface, around which there is a circular shadow artefact. Increasing the grid resolution in both directions reduces this, but making it negligible raises the memory cost and GUI rendering burden considerably. This is a drawback to this approach.

So here is another suggestion: using a rotation of a spherical coordinates plot over a different range, created so that the "parametric seam" lies horizontally along the edge of the spherical surface -- essentially becoming hidden.

H2:=plots:-display(
     plottools:-transform((x,y,z)->[x,z,y])(plot3d(3,th=0..Pi,phi=0..Pi,
                                                   coords=spherical)),
     plottools:-transform((x,y)->[x,y,0])(plottools:-disk([0,0],3)) ):
plots:-display(H2, scaling=constrained, orientation=[180,77,170], style=surface);

You can manually rotate that 3D plot and notice that neither of the previous two kinds of shadow artefact are visible. I think this is a better solution, for the case where style=surface is used.

I'll move on to a couple of relatively minor points.

Carl showed how you can put a circular cap below the hemisphere, to make it appear as a solid, and I have no complaint about how he did it. I'll mention that there is memory savings possible since the radial grid-resolution of the cap only needs to be 2 rather than the default 49, if the surface grid-lines don't matter or aren't wanted. (The disk's circular grid-lines don't match those projected from the spherical portion, even in the original.) The following is almost half the size in memory, and for rendering multiple 3D plots that difference can really affect GUI performance.

plots:-display(
  plot3d(3,theta=-Pi..Pi,phi= 0..Pi/2,coords=spherical),
  plot3d([r,theta,0],r=0..3,theta=-Pi..Pi,coords=cylindrical,grid=[2,49]),
  scaling=constrained);

Also, If the original is shown magnified then some non-smooth points along the outer circular edge are discernable, especially when the grid-lines are shown. So, optionally, one could re-use some of that saved memory space and also increase the theta grid-resolution. Eg. the following produces a smoother, rounder edge and surface:

plots:-display(
  plot3d(3,theta=-Pi..Pi,phi=0..Pi/2,coords=spherical,grid=[106,70]),
  plot3d([r,theta,0],r=0..3,theta=-Pi..Pi,coords=cylindrical,grid=[2,106]),
  scaling=constrained);

I think that last is a decent solution for the case where the wire-frame grid-lines are wanted (including the default style).

Lastly, I'll mention that I really don't like what plottools:-hemisphere produces for both spherical portion or base disk: a visually inferior collection of polygons with visible edges, and much less flexible coloring functionality. It's awkward and memory intensive (and burdensome on the GUI) to get something even approaching a very smooth surface with this approach.

Your first example (Q1) might be handled as follows, using the Logic:-Complement command which was introduced in Maple 2016.

restart;
with(Logic):
local O:

P1 := (&not O) &and (&not C) &implies (&not Q);

Complement(&not(P1));

See also,

Complement(&not( A &implies B ));

Lc_ac.mw

Of course, you can combine this pair of commands into a single statement, without utilizing a temp assignment, eg,

   subsop(ListTools:-Search(1, L)=NULL, L)

If the specified element is not present in the list then that would throw an error, naturally, about use of an improper op or selector.

Download ListSearch.mw

In a .mw file Worksheet/Document you can make an imported Matrix be the data (rtable) associated with a DataTable Embedded Component.

You don't need to utilize any special commands to further access that Matrix data -- simply use the name to which the Matrix is assigned, in usual ways.

A Matrix associated with a DataTable by name is stored in the Worksheet .mw file, and automatically accesible following restart or Close/Reopen.

You can even toggle off the visibility of the DataTable, effectively hiding it from overt view.

The above is one way you might accomplish the question as asked -- to actually store the data in the Worksheet so that it is accessible upon re-opening without need for re-import.

If you merely want to automate and hide the step of importing from the data file (.csv file, etc) then you could place the importing command inside the Startup Code region of the Worksheet/Document.

Did you try using the full path to the file? Eg,

   "C:\\\\Users\\Sriram\\Downloads\\temp_file.txt"

or,

   "C://Users/Sriram/Downloads/temp_file.txt"

Note that backslashes are escaped with an extra backslash (each). Most relevant commands in modern Maple also accept single (unescaped) forward slashes.

You can force specific tickmark positions, as well as get the formatting you described. For example,

plot(x, x = 0 .. Pi/2,
     xtickmarks=[seq(n*Pi = Typesetting:-Typeset(Typesetting:-EV(n*Pi)),
                     n = 0 .. 1, 1/10)]);

You could also reduce the font size, eg.

plot(x, x = 0 .. Pi/2,
     xtickmarks=[seq(n*Pi = Typesetting:-Typeset(Typesetting:-EV(n*Pi)),
                     n = 0 .. 1, 1/10)],
     axesfont=[Times,9]);

@AzU You can show the form in a few ways, eg,

de_mat.mw

In your first three examples you wrapped the plotted expressions in calls to abs.

But in your last two examples you used A[1] which is not real-valued for almost all of the specified domains.

Notice that the results for A, coming out of solve, do not contain calls to abs. (Whether you agree with what solve produces, or not, is another matter. You can see the form of your A[1]. The last two examples' plotting results follow from what A[1] happens to be.)

These plotting commands need something real-valued (or with a very small imaginary component which could be taken as a round-off error artefact). The first three examples do that, but the last two do not.

I don't know whether you understand what happens when you wrap such expressions in calls to, say, abs, or Re, or Im. Using your A[1] expression, have a look at the result of,
    plot([Re, Im, abs](A[1]), x = -6 .. 6)

Here are two closely related approaches to coloring the contours by hue. I used only the ColorTools:-Color command here, for the coloring of the curves.

I used a sequence of plots:-implicitplot calls, for the contours. That allows for some convenient ways to specify the coloring method. You could also pass additional options, eg. grid=[41,41] or gridrefine=n, etc, to improve the curve resolution.

I also used one of the plot3d color-function methods (and commented out a colorscheme alternative). But that was mostly to illustrate the difference in the two approaches shown for the curves.

The first approach has the contour colors range over the full hue range. The second has the contour hues scaled relative to the z-range attainable over the full, specified x-y grid.

You could also utilize hue ranges from 0.0 to 0.85, or Red to Magenta, or your preference if you don't want the full cycle. But the above choice would still exist: should the contour hues extend over that full range, or be scaled relative to the z-range attainable over the given x-y ranges?

Download contourplot_hue.mw

Without that transparency adjustment the PC2 colors would be a very close match to those in the PS density-plot. I adjusted the transparent so that we could see that they were indeed overlaid together. And, of course, you could make other adjustments and overlay them deliberately.

Some related plot coloring pages:
  plot3d,colorfunc
  plot,colorscheme,coordinates
  plot,color
There are several other ways to color contours according to some function f(x,y).

If you want something else then you should really be very clear about exactly what you want, how the colors relate to the function as well as its supplied plotting domain (ranges), etc.

So far you have not stated precisely what you want. The citation to the wikipedia Domain-coloring article is still ambiguous.

One simple way is to use a later version,

Download Mean_RV.mw

You wrote that there is no unit with symbol M for molar concentration.

But you could add such a thing, with the Units:-AddUnit command.

chemistry_units_ac1.mw

You could also make that new M unit the default (prefered unit) for simplification for expressions having dimensions the same as mol/L and say (mol/L)^2. You could also load the Units:-Simple package, so that simplification and combining of units occurs automatically when using its bindings for arithmetic, etc.

chemistry_units_ac2.mw

Also, the code to define a new unit, and set it as default, could be tidily hidden away inside the Startup Code region of the document. (I won't suggest putting those in an initialization file, or else other people wouldn't see the same results when rerunning the document.)

I got the impression that you'd prefer to see the unit M for molar concentration. If you would actually prefer the literal (mol/L)^2 then please say so. It might be achieved similarly, with the symbol a typeset identifier (name) of (mol/L)^2, or (mol/L)^(-2), instead of 1/M^2, etc. But reciprocals of those might get difficult to handle well.

The first pair of parantheses (brackets) does grouping of terms, to assist with the precedence.

The second pair of parentheses does the functional application, ie. forming function calls.

Here is an example of only the second kind:
    sin(x)

Here is an example of both kinds in use together:
    (sin+cos)(x)
which returns   sin(x) + cos(x)  .

The following shows the role of grouping. Compare these two examples:
    (f+g)(x)
which returns   f(x) + g(x)  .  And now,
    f+g(x)
which returns   f + g(x)   which is the addition of the term f and the term g(x).

The first pair of brackets in   (f+g)(x)  serve an important purpose, for grouping of terms, which makes it quite different from say   f+g(x)   .

The key thing here is which takes precedence -- the function application or the addition. The first pair of parentheses in  (f+g)(x)  allow us to force the addition as preceding or taking precedence over the function application denoted by the second pair of parentheses.

Now something subtler. Suppose that g is unassigned at present, but later on may get a meaning such that g(x) returns something which can itself be applied to arguments. The expression  g(x)(t)  denotes the symbolic placeholder g(x) applied to argument t. So, we can meaningfully apply g(x) to something else, and use it like an operator.

In this rich world we could compose operator f with the placeholder g(x) for some (as yet unknown operator).  So now,
    f@g(x)
denotes the composition of those two operators, f and g(x). This conceptual composition of operators is not itself being applied to an argument. But the result is indeed a meaningful expression, and is not nonsense.

Now compare that last example with this,
    (f@g)(x)
which represents something quite different. This denotes the composition f@g applied to argument x, which results in   f(g(x))  .

The first pair of brackets in   (f@g)(x)  serve an important purpose, for grouping of terms, which makes it quite different from say   f@g(x)   . 

The key thing here is which takes precedence -- the function application or the composition. The first pair of parentheses in  (f@g)(x)  allow us to force the composition as preceding or taking precedence over the function application denoted by the second pair of parentheses.

I hope that helps some.