@acer 

Thanks a lot for your help, now it's working.

Actually there were 2 things which didn't work in the previous solution. The first one was that there were additional spaces between the 2 words, I don't know where they come from.

The other thing was that I was missing the "eval" statement. I still fumble in the dark when to use "parse", and when to use "eval". Right now I try one of them first, and then the other one. It seems that I need both of them in this case.

Last thing to fix from my original posting is that we were talking about double quotes, and not apostrophs...

joinStr_ac_mod1.mw

@tomleslie 

I've modified the code a bit, and transformed the code to something easier to check for everyone.

Right now the code doesn't work yet. It's based on the StringTools solution, but I think the problem would be similar in the other solutions.

joinStr.mw

@ecterrab

I can confirm that.

https://www.mapleprimes.com/questions/230994-Package-Install-Problems

Today a new release came out - and it fixed the problem (at least on my PC).

Download from Maple Cloud apparently now works.

I think it should be considered to add a new type of variable especially for workbooks to Maple.

Right now there are those types as far as I can see.

• local variables
  variables within a procedure
• global variables
  variables outside of a procedure, but within the same worksheet. Their values are however not stored between sessions.
• "persistent variables"
  Those are global variables, that are stored in an embedded components. Those values are persistent between sessions,

I would prepose a type of variable that is both persistent between sessions, but also accessible from different worksheets in a workbook. Those variables could be stored in a special workbook folder, like code is already stored nowadays.

This new variabletype could be called "meta", or "super" or something like that.

@Joe Riel @acer

Thanks for the clarifications everyone.

I guess that's a definite answer then and I'll have to accept that.

@acer 

I don't agree with your point of view at all.

Do you have any example where that would be useful?

@tomleslie 

I think I finally found what I want.

https://www.maplesoft.com/support/help/Maple/view.aspx?path=Maplets/Elements/AlertDialog

@tomleslie 

Ok, thanks for the answer, though I am not sure if that is exactly what I need.

In my case the problem is not so much an error, but more a possibility to give the user a feedback about a specific thing.

More like "No, your input is not possible, it violates blablabla.".

Are there any tools, like popup boxes, etc. that can be used for that purpuse? Maplets?

@acer 

Is it possible to do that on existing tables too?

TableLayout.mw

I've filed a software change request on that one.

@Joe Riel 

One thing is when the call is in the embedded component, and I do agree that there should be as little code there as possible.

But the problem is pretty much the same when the call is indirect, where the buggy code is somewhere else.

It would be much better if Maple raised an exception - sorry, I didn't find that.

Modified code attached.

ProcNameWrong.mw

@Preben Alsholm 

Thanks for the tip.

Which more or less proves my point - the implementation of the max and min functions in Units:-Standard code is buggy. It should be rewritten to take into account that the values can become zero.

I'll file a bug report.

Yes, that's what I found out as well.

I think the reason is that the Simple version uses the "original" max and min functions, while the Standard version has a new implementation - which in this case, fails to do the job.

There would be a possibility to use the verify function in a way to go around the problem, but this requires a bit more coding. The reason behind the problem is that Maple loses units when coming to zero, as mentioned before. That should never happen.

verify( a, b, units( less_than ) ); # true

@acer 

I guess I have to take your code as given from higher spirits, because I don't understand a thing about what it is doing.

Just checked the results of xmldoc and xmldocA, and they seem absolute identical. Both are of type function.

[Edit]

I've found a more direct solution to the problem by using a different function which works.

numelems(GetChildByName(xmltree, "materials")) > 0