I have attached two files - Loads - Gravity and Test. Test includes (Loads - Gravity). I have stripped everything out of Loads - Gravity except for what seems to be causing the issue. The issue is that the Combobox will not work in the test.sm file. I'm not sure why. I can delete any of the like colored 'regions' in the Loads - Gravity file and the combobox will work in the test file. There seems to be no correlation, but maybe someone can point me in the right direction (so long as it's not "don't use include() :d ).

Test.sm (3 KiB) downloaded 129 time(s).
Loads - Gravity.sm (15 KiB) downloaded 114 time(s).
(Make sure files are in the same folder)

Thanks!

Basically, q.LLResult is defined but not defined (is defined in the worksheet but has no Answer), this triggers the exception.

Fixed. Thank you

ComboBoxList/NumericUpDown/Slider regions updated.

No, Thank you!

I'm not sure I understand though.

Isn't q.LLResult defined as a system of equations (which was the result of the function)?
Or is a system of equations not considered a 'definition'?

Thanks again

Wrote

Isn't q.LLResult defined as a system of equations (which was the result of the function)?
Or is a system of equations not considered a 'definition'?

As explained by Viacheslav here include doesn't load the regions (any region), it loads only the xml code of the math regions. Hence, the ComboBoxList in "Loads - Gravity.sm" acts like it is disabled -> the output value K.LL is an unknown -> q.LLResult is not defined because not all the arguments are defined.

As stated before (I can't find the thread) probably it is possible to provide a fix working on both sides (include plugin and any region plugin that feed the canvas with values, adding a hook in the xml), however the behavior would be static (what is saved is what you have).

Davide
this is very clear from a SW developer standpoint or for someone that has at least attempted to develop a plugin ..but for a normal user is not easy to understand .
But it is however Highly appreciated the post.

Best regards

Franco

... little bobo in the first transmission
repaired ==> run ... NotePad => NOT needed

Note this: the function may have another
construction style [book style], Smath
will automatically convert to its own code
i.e: a 1/1 equivalent

File Spool Fnct Param Reference.sm (11 KiB) downloaded 81 time(s).

ioan -

Quote

"As long as you haven't saved the file with the deleted colored regions",
if not... Farewell to your function...Smile

Yes, you are right, good catch.

In regards to your argument against include(), you are probably right. I tend to have characteristics that don't align with most engineers and probably makes for a bad program. Speed and ease is of the upmost importance and sometimes that leads me to be brash in my ways. When I say speed I mean the pace at which I work not so much for my programs as you have seen. This is quite the paradox/oxymoron as then I get angry at Smath for moving so slow.

So I will admit that read/write is the way to go, but here is my 'argument' for using include.

1. It's easy. If an engineer who has not used Smath needs to start adjusting read/write variables this may complicate things for them.
2. Currently I usually only include 2 or 3 files which are the "Loads" files. So there is not a terrible nest of include statements.
3. I don't have anything setup using read/write.

All of these are poor excuses I know. I've have been wanted to post some examples calcs to get feedback on how to improve them. First I need to update the calcs though. Maybe through this update process I can incorporate the read/write function.

Thank Ioan, I understand where you are coming from. I was sorta playing Devil's advocate.
Thanks again!

Ioan, there are far more complex issues than the realization of the full functional include().

Current version of the function is unlikely to be improved. I created it as a crutch until you see the full version which only Andrey can give. I understand your wishes as to what it should do. I assure you, if I knew how to do it, I would do it. As for the ComboBox, and other components, yes, they are ignored. This function works as a text file parser. It works only with the data that can be recovered "manually" from the file. In fact, to load an external file it is necessary to use a set of built-in functions. But they are not available for the simple function from a plugin. That's why I wrote that it is impossible to calculate the state of the ComboBox and other visual components (for now). Yes, I can parse data from file but I can't recover the state of object in a proper way. Therefore, in its current form it is a dead end road. My advice is to use the function only for simple applications (a set of constants, functions, etc).

Maybe something can do, if create a function in the form of a component, as proposed by Martin (Hyperlink + include = Mathcad Reference).

Now I'm trying to think of how to improve the components for drawing graphs (X-Y Plot, ZedGraph, NPlot, ...).

Davide -> I updated the plugins but I still seem to have the same issue. Should I be getting a different result?

Thanks

Wrote

For me it's enough interesting if we can include already build functions form various individual files, for avoiding copy/paste or snipets.
My simply question is if there are in such cases some invisible "collisions" risks, by the use of many "included" functions in a file.

It is necessary to avoid recursion. I still can't catch this type of error in all cases. The only thing to keep in mind - it is the replacement of definitions. But I think this is normal behavior. Or you can suggest the rules how to resolve such kind of collision.

Wrote

Davide -> I updated the plugins but I still seem to have the same issue. Should I be getting a different result?

Thanks

The error in the comboboxlist (or other controls plugins) shouldn't be triggered anymore.

Wrote

My simply question is if there are in such cases some invisible "collisions" risks, by the use of many "included" functions in a file.

include has a lot of potential, being able to run several worksheets at once from a single worksheet (as stated by you, a sort of improved snippet); the possible collisions (if you don't know the limits):

1) regions with an output to the canvas are not managed -> you may expect values are processed by the regions in the included worksheets, this doesn't happens;
2) there's not a check on the dependancies -> running the worksheets on another system you may miss the required plugins or (in the worst case) a different function with the same name of another (from another plugin not available in the source system) may be incidentally used with unpredictable results.

Yes, Davide is right, I forgot about the dependencies. Other worksheets are calculated in the current document environment. This is an important point.

Wrote

Thanks Viacheslav for your interesting lights.

For me it's enough interesting if we can include already build functions
fomm various individual files, for avoiding copy/paste or snipets.
My simply question is if there are in such cases some invisible "collisions"
risks, by the use of many "included" functions in a file.

Best Regards,
Ioan

Snipet ... snipet of what ? A snipet of a piece of program,
good idea but no way. A program is local in work sheet, it
can't be converted to "mat2sys", therefore: zap to be spooled
somewhere/somehow. Copy/paste the snipet example delivered with
5346 does not work.
An Engineering document that is not stand alone and not printable
will not pass my QA, as not beeing tracable. One can use a formula
from source as long as a the source is visible. All these monkey
business wish list will fail in Court Case. Experts, the Judge, if
they don't see the A ... Z in printed document, there is no Court
Case because there is nothing to be examined and stored.

include("string") - include sm-file.

I haven't seen an example of that, working.

To me, "include" is floccinaucinihilipilification
i.e: explain/debate the useless with no words no fish to catch.

Jean

I can see "include" as a plugin utility doing all utilities
already collected and that it would update automatically as
per user developping more. In other words as a personal
plugin. For functions as single "model function" no need for
"include", why ? WRITEFILE/READFILE does it well already.
For work sheet as re-usable: not needed. Copy/paste project
done for JoBlo, paste in SueZan work sheet, adapt wrt her
project specifications.

Jean

Solve Maple [DE] Spooled.sm (13 KiB) downloaded 65 time(s).

Hi all
2D Plot does not work with units
I tried to plot a function according the instruction of Sebastian Schluricke shown at www.youtube.com/watch?v=AtICkHXHFpk
His example I could easily do. But as soon if I go over to my calculations where I work with units I cannot plot them. I receive only the message variable not defined.
What is wrong here?
Kind regards
Gaselhul

Salut Ioan,

I most appreciate your convincing demo.
Happy users if "include" 5346 works for you.
Dead for me, I don't care much.
Now: plugin & plugin ... as an individual user
fine as Smath a permanent "beta version". For
clients [remote clients] ... NO way to update
day by day as plugins arrive and often not
fully proven [not a critic].

Smath is like Mathcad was: you need a huge tool
box to fully exploit. Several hundred of tools.
At this point, a list of tools is needed and
must be updated ... something like Matlab
10 km long. Personal tools may be at risk !
My hart for Smath abounds for more essential
functionalities [clipboard ...] and more maths
[fft, integration, ... the list is long]

Most interesting is like this:
If Samth users find my Smath tool box profitable
to "include", it's possible to collect, will take
quite a while to group ~ 150 work sheets with minmum
application examples ... just going back to Smath
repository that was not so much welcomed.
Maybe Smath does not want to become a winner like
Mathcad 8 Pro. did.

Cheers to all, Jean