How to extract volume infos non interactively

[marco]

Hello there. I work with workmanager, but this is really a Modeling/SD issue.

I am trying to extract volume and mass infos from SD to update a weight attribute of some classes in WorkManager, during saving.

I found a command, get-vol-prop, that works perfectly in a user dialog:
(setq pesoun ( / (sd-call-cmds(get_vol_prop :for_part object :mass)) 1000) (where object is a selection)

Unfortunately it doesn't seem to work outside the dialog. I tried to use it with a sel_item object as an argument, but without success. Maybe because it is classified as an "interrupt function"?

Is there any other function I can use to inquiry mass properties? I tried to look for in the IntegrationKit docs, but no luck.

Thank you for your help

Marco Coli

[Markus]

Hi Marco,

try to replace sd-call-cmds with the not documented function getres . That should solve your problem.

Cheers,
Markus

[marco]

Originally posted by Markus
Hi Marco,

try to replace sd-call-cmds with the not documented function getres . That should solve your problem.

Cheers,
Markus

It worked perfectly!!! You saved me, I really thank you very very much!!!!

There is a list somewhere of not documented functions, in case one need them?

[Markus]

Originally posted by marco
There is a list somewhere of not documented functions, in case one need them?
Of course not :D !

Markus

[ChrisE]

Hi Markus,

why "getres" (undocumented) instead of "sd-call-cmds" (documented) ? :confused:

Are there other SD commands that won't work with "sd-call-cmds" ?

Cheers,

Chris :cool:

[marco]

Originally posted by Christian Ernst
Hi Markus,

why "getres" (undocumented) instead of "sd-call-cmds" (documented) ? :confused:

Chris :cool:

I can answer for this part: sd-call-cmds does not work, if used outside of a dialog (try from command line, for example, or in a macro called from workmanager via interlink).

[Wolfgang]

Yes, that's true.... and shows you immediatly a supported way to workaround the problem.


(sd-defdialog 'doit-for-me
:dialog-control :sequential
:variables '((the_part :value-type :part))
:ok-action '(setq pesoun (sd-call-cmds(get_vol_prop :for_part the_part :mass))))

(doit-for-me :the_part object)


pesoun should be global then.. but the OSD functions in use are all supported then.

This ís a way I'm using sometimes to test tiny things on the command line.. just a wrapper dialog around.. and ready.

[marco]

Originally posted by Wolfgang
Yes, that's true.... and shows you immediatly a supported way to workaround the problem.


....



Yes, but this code doesn't work if you need to call a SD Lisp macro from WorkManager through Interlink. Getres does.

[ChrisE]

Hmm, got no problems calling such OLI-code per DDE (WorkManager Windows)

Example:

(in-package :CHRIS)
(use-package :OLI)

(sd-defdialog 'doit_for_me
.........sd-call-cmds ...
)

Then from WorkManager, I can call my routine using

LET r (DDE_EXECUTE dde '(CHRIS:doit_for_me "/p1")')

and it seems to work (for me)

What's looking quite weird is the result:
If I was to request the value of the global variable (I exported it inside my package), I receive GARBAGE. Real garbage. Using DDE_REQUEST.
Displaying the variable inside SD shows the expected result (some large figure).

Haven't got a UNIX box at hand at the moment, so I can't check with DMSIntf.

[ChrisE]

Originally posted by Christian Ernst
.....
What's looking quite weird is the result:
If I was to request the value of the global variable (I exported it inside my package), I receive GARBAGE. Real garbage. Using DDE_REQUEST.
Displaying the variable inside SD shows the expected result (some large figure).
....

Stupid me :mad:

DDE_REQUEST can only pull string values!
==> I had to convert the result into a string first. Now I receive the value I expected in WM.

[Wolfgang]

I didn't know that you get back a string result with DDE_REQUEST at all. Nice to know.

Is the other way around working, too?

something like this from OSD:

(display (oli::sd-dde-execute my-ddm-handle "inq_env 0 (inq 301)")) ?

but now we are going off topic.... (how to set a FUP2 here..)

[ChrisE]

Well, not really off topic, we could as well be requesting data from WM.

And that didn't work for me :confused:

I tried the following commands:


(setq handle (oli:sd-dde-initiate "HP_WORKMANAGER" "GENERAL"))
(display (oli:sd-dde-execute handle "INQ_ENV 0 LET DDE_RES (INQ 301)"))
(display (oli:sd-dde-request handle "DDE_RES"))
(display (oli:sd-dde-close handle))

==> sd-dde_request always returned :ERROR :confused: :mad: :confused:

The global variable DDE_RES exists within WM, and is of type STRING. So I don't quite understand.

I tried the same with ME10 (aka Designer Drafting), and it worked fine!

(setq handle (oli:sd-dde-initiate "ME10F" "GENERAL"))
(display (oli:sd-dde-execute handle "INQ_ENV 0 LET DDE_RES (INQ 301)"))
(display (oli:sd-dde-request handle "DDE_RES"))
(display (oli:sd-dde-close handle))


Now I wonder what happens between ME10 and WM ? Haven't tried it yet, but I sure will ! Wondering if it is a general bug of WM.

[ChrisE]

Originally posted by Christian Ernst
......
Now I wonder what happens between ME10 and WM ? Haven't tried it yet, but I sure will ! Wondering if it is a general bug of WM.

Well, it seems as if I can't request global variables from WM. I tried the following from ME10, and vice versa:


LET dde (DDE_INITIATE "HP_WORKMANAGER" "GENERAL")
DISPLAY (DDE_EXECUTE dde "INQ_ENV 0 LET DDE_RES (INQ 301)")
DISPLAY (DDE_REQUEST dde "DDE_RES")

==> ERROR :mad:

Vice versa (WM requesting data from ME10) works fine :

LET dde (DDE_INITIATE "ME10F" "GENERAL")
DISPLAY (DDE_EXECUTE dde "INQ_ENV 0 LET DDE_RES (INQ 301)")
DISPLAY (DDE_REQUEST dde "DDE_RES")
DISPLAY (DDE_CLOSE dde)

==> works fine without error!

So is this behaviour a bug or a feature (or simply working as coded) ?

Can't remember having ever pulled data from WorkManager using DDE_REQUEST - so I can't say if that is a new feature, or has been around for a while.

I'll send this to the support team. Maybe they have an answer to it.