The one "answer" I got was not a complete answer for my purposes, but it was a very strong clue to an answer. The argument to randomize used in the reply was the integer 1.

The fact that this worked indicated that perhaps seeds can have only a maximum number of digits. Doing some quick experimentation I found that seeds must have 9 digits or less.

Apparently, if the seed has more than the maximum number of digits, the procedure doesn't simply truncate but seems, instead, to go to the system for a starting value as if no initial seed had been given. The output from randomize, however, does give the seed that was given in the argument, which fools you into thinking the seed was acceptable.

This is not documented on the randomize or SetState help pages or any other page that I could find. 

From Christopher, it would seem that the code worked in Maple 12, but a bug (or undocumented behavior) has been introduced by the time Maple reached Maple 16.02

On the other hand, Acer and Preben have functions which work. What general cases does transform work for? The Help page is quiet on this.  The answer seems to lie in the procedure `transform/object`. Acer and Preben, did you have access to the code for that procedure, or did you discover your fixes by quessing and trial and error?

Does anyone know how to see the code for `transform/object`?

PS:  I really meant 2*Pi in the plot, but that is not really essential to the "bug". 

I have noticed a strange phenomenon: I had been using my user account on XP (without administrative privileges), so I switched to my administrative account. Interestingly, the problems did not occur. So were they related to permission problems? Well, then I switched back to my user account. Here, amazingly, I discovered that the problems had disappeared. What? Did some Mapale code need to be "warmed up" by being first run in administrative mode? Well, if this continues to be true, I am happy but perplexed. If this is really true about the Maple code, their installation process (or at least update process) needs to be tweaked. If there are any other ideas, I would like to hear them.

P.S. I am not really sure what "such problems" are. But they were all real, and many continue to exist but are undocumented by Maple, although some were cleared up by updates. For instance, if you wish to split a line inside a  command's parentheses or data structure definition which already has its ending separator, the cursor will go to the next line along with whatever follows the separator. No breaking up completed commands or data structure definitions. You must first remove the separator, and maybe some that follow it if it is nested. Once the separator is there, that part of the statement is parsed and considered a whole with only the existing line breaks. Making these breaks, of course, allows me to make the worksheet visually easy to read. But, of course, that is just one of "such problems", "I" always have. You might also look at one other "such problem", the problem of trying to use LinearAlgebra for symbolic calculations. O well, those are just my quirks or is it a supposed lack of knowledge? You might also look at my contribution on taking numerical derivatives with a system of equations.

This applies to a text group.

I does appear tht the cursor actually, though often invisibly, moves when the arrow keys are pressed. If I start out by making a number of blank lines so that the (visible) cursor is at the bottom line and then press the up arrow key a few times, the visible cursor stays on the bottom line and no other cursor appears. However, when I type a letter, it appears on the line where the cursor should be, the cursor at the bottom disappears, and no new cursor appears. If I double click right after the letter, the letter becomes highlighted, but with one more click the highlight goes off and the cursor appears after the letter.

If I again create a number of blank lines with the cursor on the bottom line, I can go up and one by one double click on each line. The result is a cursor at the beginning of each blank line.

Now start out with a word at the beginning of a text group line. If I ckick between each letter in the word, I can get a situation where there is a cursor between each letter in the word and at the end. The cursor placed last actually determines where a newly typed letter will go.

Thus the true cursor seems to always exist in the correct location but may be visible or invisible. On the other hand, there may be visible cursors, even many, which do not indicate the actual location of the writing cursor. Thus the code seems to have a multiple personality, one part of it knows where the writing cursor should correctly be, while the other part which runs the visible placement cannot follow in real time although it does seem to evenually catch up. This observation should allow someone to locate the bug in the code. 

All the actual handling of math in the .tex file produced by Maple is done through the \mapleinline function which has four arguments. It seems to ignore the first one (active/inert), but does pay attention to the second one (1d/2d). If its value is 1d then the stuff in the third argument is what LaTeX will print, while if its value is 2d, then LaTeX will print the stuff in the four argument. Even if the actual maple input is in 2D, the Maple export facility seems to translate that into its 1D equivalent and put that into the third argument. The stuff in the fourth argument is the generated latex code, but it is blank for inputs and only supplied for outputs. Why does it not provide LaTeX for 2D input? First big question. Anyway, one can edit the .tex file to get 1D input printed even if the original input is 2D. Simply, change the 2d to 1d in the second argument, AND remove the % before the second argument so that it is no longer commented out. Voila! Input appears in the priinted output. Another very strange behavior of the export to LaTeX facility is that, even for outputs, it only generates LaTeX code for the part of the output that would correspond to the ditto operator %. Thus if the actual Maple output is "a:=10", one will only see "10" on the result line. Why? Second big question. To change this one would have to actually add LaTeX code to the fourth arguement of \mapleinline, although generally not a lot. Finally, if the original worksheet (or any part of it) uses 1D input, that input is indeed printed. (Maple simple does what I suggest, 2 paragraphs above.) Also if one uses the classic interface, then not only is the input printed but ALL the output is printed. All this behavior is particularly strange since Maple can clearly generate LaTeX code for 2D expressions. So why the restriction to "ditto output"?

I am in the process of examining Maple generated .tex files and their .sty files. It is immediately clear why the input is missing in the final output files: All the input expressions are in the .tex file, BUT they are all commented out, i.e., a % sign is before them on the same line. Simply eliminating the % does not improve things, so there is also a deeper problem in the functions in the Maple .sty files which are used to process these lines. Also, only the real "output" of the maple input is printed, that is, the output that would be given by the % in Maple. The lhs of an assignment statement is not printed. That occurs because that part of the output is not present in the .tex output from Maple. Thus this lack is related to how maple produces the .tex file, not in the behavior of its .sty files. What isn't in the .tex file can't processed. I have also determined that some routes to a pdf file, at least using WinEdt, produce the eps graph and some do not. I seem to have to first produce a .dvi file explicitly and then use dvi2pdf to get the graph to appear. The more direct route LaTeX2pdf does not show the picture. That probably has something to do with one of the .sty files not passing the appropriate driver name to the gaphics package for this shortcut route. Maybe that could be changed in the Maple generated .tex file by changing one of its .sty files. But this is just a very very slight inconvenience compared to the missing input lines and half the output.