Subscribe to this thread
Home - General / All posts - Manifold 9 - problem with add-in that uses a form
Sloots

678 post(s)
#04-Dec-19 12:21

Hi,

I'm making my first moves in the world of add-ins for M9. I'm trying to open a form where the user can select e.g. which drawing to use (within the add-in). To get access to all the Manifold stuff I'm passing the Manifold.Context variable in the constructor (public static M.Context Manifold; and then in the Main function something like this: MyForm frm = new MyForm(Manifold);)

The form opens perfectly, and in the constructor of the form I can access everything that the api exposes.

private static M.Context _manifold;

public TSPForm(M.Context manifold)

{

_manifold = manifold;

// here I can access things e.g. Manifold.Application app = _manifold.Application;

}

But when I try to do this:

private void button1_Click(object sender, EventArgs e)

{

M.Application app = _manifold.Application;

using (M.Database db = app.GetDatabaseRoot())

{

// this fails!!!

}

}

it fails, although _manifold is not null. db appears to be null.

Am I missing something here...?

Thanks for some insight.


http://www.mppng.nl/manifold/pointlabeler

tjhb
10,094 post(s)
#04-Dec-19 18:50

I will learn something here too.

Can you post more of your code? Possibly something that can be tested, but not necessarily.

First, is this a script, to be compiled and executed within Manifold, or is it a free-standing application? The requirements are different.

Where is M declared and assigned? Sometimes you are using M, sometimes full Manifold.

If it is a standalone application, have you assigned the STAThread attribute somewhere?

Riivo's checklist might help.

adamw


10,447 post(s)
#16-Dec-19 11:58

M is probably just -- using M = Manifold; -- a shortened name for the Manifold namespace. We commonly use such shortening in our .NET code and I think we used it in script examples in the API doc.

adamw


10,447 post(s)
#16-Dec-19 11:56

Right, hope I am not too late.

Could you post the code of your Main? Is the form modal or modeless? It has to be modal currently. That is, calling into the add-in should only return control to the application when the form is closed. If you show a modeless form, then return control to the application (to allow the user to use the Project pane, etc), the script context that the form runs on will be cleared and attempting to access its objects will return nulls.

We *did* have means to keep the context alive after the add-in returns control to the application, but we weren't entirely happy with how they worked (the rules were somewhat difficult to follow from the add-in side and if you didn't follow the rules, the add-in was producing accumulating leaks of memory and resources), so we took them off and put the entire topic onto the bench for the future. We can get back to this, no problem, it's not super-difficult to do, so if that's your stopping block right now, tell us. Or try a modal form first.

Sloots

678 post(s)
#16-Dec-19 16:30

Thank you for your reaction. I will try to use a modal window, no problem.

@tjhb: M is indeed a shorthand for the manifold namespace.


http://www.mppng.nl/manifold/pointlabeler

tjhb
10,094 post(s)
#16-Dec-19 16:32

(My very small point was that for some reason you were using both.)

tjhb
10,094 post(s)
#16-Dec-19 18:55

I was wrong. You were using M for the Manifold namespace, _manifold and manifold for instances of the Context object.

I often find this reusing of names confusing. E.g.

static Manifold.Context Manifold;

I think that should be just banned.

It is worse if you have previously defined M (for example) to stand for the namespace. Then the labelling is circular.

In my opinion, if a Context object requires a name, it should be something that reflects “Context”, definitely never the name of the containing namespace. I don’t know C# at all well, but that just looks sloppy to me, bound to confuse new players.

adamw


10,447 post(s)
#17-Dec-19 07:49

No disagreement, two different uses of 'Manifold' have been bothering us, too. We didn't fix it because we really like the main object to be named 'Manifold' and the name of the namespace is just naturally 'Manifold'. Maybe we should just let the main object be named ManifoldContext or something (maybe: Mfd).

tjhb
10,094 post(s)
#18-Dec-19 07:00

Thanks. I probably disagree with myself a bit now though.

Both names make perfect sense individually, just as you say--and it's hard to think of anything better tor either of them.

The only problem (out of my pair of eyes) is that it can be confusing to someone trying to read and digest syntax that is unfamiliar. "Same means same" and "different means different" are helpful assumptions when making sense of unfamiliar patterns.

The resemblance doesn't arise for (Iron)Python because it is a dynamic language. We don't need to declare what Manifold is explicitly, since at runtime there is only one Manifold in scope, defined behind the scenes as the Script.Manifold property, referring to a Manifold.Context object. (It's also a duck.)

Same for vbscript, since it is interpreted.

It's only for a language that imposes compile-time type checking that the two names sit side by side.

So I think a simple note in the API doc would be better than a change. It seems enough to reiterate what each instance of "Manifold" refers to, and to explain that the duality only appears for strongly-typed languages.

Sloots

678 post(s)
#17-Dec-19 15:06

Changed my window to modal and .... voila! It works as expected. Can't wait to implement the TSP add-in...


http://www.mppng.nl/manifold/pointlabeler

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.