Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Uffe

Pages: [1] 2 3 ... 22
1
Hullo boys and girls,


How DO you distribute ribbon sets to other boys and girls who might want to play with them too?

Once you've made your ribbon set all nice and neat, you'll find it squirrelled away in the secret box %AppData%\Roaming\Sparx Systems\EA\RibbonSets.xml -- but that's your very own special secret box that no one else can touch.

Now in there, you can write in your best handwriting a "techid" to which the ribbon set belongs -- but that's just telling fibs because it's nothing to do with any MDG Technologies at all, now is it boys and girls?

You might think that copying the whole XML structure into an MDG Technology file would make our beautifullest ribbon appear in in the other boys' and girls' GUIs, but no! Calamity! That doesn't work either!

So how DO you do this, boys and girls?


/Uffe

2
OK Dudes, are we ready to rock?


I'm working on a style sheet based on Numbered Headings - Black.

I've done some basic stuff to Heading styles, page break before Heading 1, Keep With Next on all Headings, a bit of paragraph spacing, that kind of thing. This works.

I also want to apply some formatting to the Normal style. This doesn't work.

I've set some paragraph spacing and set Keep Together (and manually corrected all the list level fonts because when you change the Normal style, EA resets the formatting in the list levels -- delightful), and while these changes are present in the exported/imported style sheet (from my MDG project to my test project), they are not applied in the generated document.

The same goes for Table Text Normal. I've modified it, made sure it's set in the table-generating template, it comes out as Table Text Normal in the generated table and the paragraph spacing is correct in the style sheet -- but in the generated document, that style has no spacing. But the same changes applied the same way to Table Heading work.

What the actual hell is going on there?

This is in 1512, btw.

Cheers,


/Uffe

3
Hey guys,


I'm working on a document generation where I want a custom style sheet (based on Numbered Headings - Black).

However, I can't find how to correctly reference the style sheet in the DocumentGenerator.SetStyleSheetDocument() call when the style sheet is deployed in a technology.

In the Resources window, the style sheet appears in a two-tier structure
Code: [Select]
Technology_name ("Technology" field in MDG creation wizard)
    Technology_ID ("ID" field in the wizard)
        Template_name

But referring to the template in each of the following ways fails (silently):
    SetStyleSheetDocument("Template_name")
    SetStyleSheetDocument("Technology_ID::Template_name")
    SetStyleSheetDocument("Technology_name::Template_name")
    SetStyleSheetDocument("Technology_name::Technology_ID::Template_name")

What is the correct way?


/Uffe

4
Automation Interface, Add-Ins and Tools / Document generation: Hyperlinks
« on: November 16, 2019, 12:30:26 am »
Hi everybody,


I've got a bunch of elements which each has a name and one (1) "Web Address" File.
I want to output these elements in a table with hyperlinks which work in Word.

There is a field {ElemFile.Hyperlink} available in the template which gives me what I want, except the URL is used both for the link target and the displayed link text. I instead want the displayed text to be the element name.

Is there a way to do this?

I've tried inserting a hyperlink in the RTF editor, and setting the link text to {Element.Name} and the link code (as it's referred to in that dialog) to {ElemFile.FilePath} in the hope that the document generation would recognize them as fields and perform the substitution, but that didn't work.

I've also tried storing a brief text in the File Note, hoping EA would pick that up and use it for the link text, but no luck.

Any other suggestions?


/Uffe

5
Hi all,


This is one of those "please read it carefully and don't confuse the issue by uninformed guesswork" kind of posts. Please read it carefully and don't confuse the issue by uninformed guesswork.


When you create a document template and a template fragment, and the fragment is of the Custom Script variety, it only works once per session when you use the DocumentGenerator API (meaning you have to restart EA after each generation).
Subsequent attempts to generate the same document fail with the parent template working correctly, but the fragment producing no content at all. If you run the same document generation from the dialog, it works every time.

Some details.

A Custom Script fragment calls a function in a JScript script, which returns XML data. Has to be JScript for EA to accept it.

My generation script which uses DocumentGenerator is written in VBScript. If that script is in JScript, the generation always fails. Presumably this is due to the same bug, but that just affects me the toolmaker, not the end users.

When I say the fragment produces no content, this includes constant stuff (table header) outside the custom> content tag. Nothing is produced.

Content in the parent template which appears after the fragment does produce output, so the whole generation process doesn't break, just the fragment sub-process.


I've tried to trace how EA executes the document generation in the two cases.

When run through the GUI, the main document generation thread appears to reside in the EA process. Each Custom Script fragment gives rise to one SScripter/conhost process pair. (SScripter is EA's script runner executable, conhost is Windows' Console Host.)
In a template with multiple fragments, it looks like the SScripter process for one fragment remains for about half a second after the process for the next fragment has started up, but that might just be delays in the reporting. (I'm using the Windows Task Manager.)

Anyway, it works as expected and a trace printout in the fragment script comes out in EA's system output window.

When run through the API, there's one SScripter/conhost process pair for the main script, so far so good.
Then, the first run through the generation script, each fragment's SScripter/conhost start up, run and finish, one at a time as above.
In subsequent runs, however, the fragment processes never start. No content is generated for the fragment, and no trace printouts appear. DocumentGenerator.GetLastError() immediately after DocumentGenerator.DocumentPackage() reports nothing.

The generation script takes far less time to run, so it doesn't appear to hang-wait-timeout but rather to encounter an error and give up straightaway. I can find no zombie processes hanging around after the generation is completed, either when it works or when it fails.

I've monitored the various temp directories, and the only one where I find activity is AppData\Local\Temp, where EA creates three temp files on startup. The VBScript generation script gets "compiled" into a file here as well, which is then passed to SScripter (and deleted upon conclusion), but the JScript fragment scripts are handled differently and are not written to any files here.

I've had a look at the SScripter command line. It looks like this
Code: [Select]
SScripter.exe arg1 arg2 "arg3" "arg4" "arg5"From what I can ascertain, the arguments contain the following:
  • arg1: A number, unknown content; probably a reference to the package being documented but doesn't match anything in t_package or t_object.
  • arg2: A number; the PID of the EA session which launched the script runner.
  • arg3: A string; the GUID of the script in t_script.
  • arg4: A string containing a decimal number; probably a magic number telling SScripter what type of script is to be executed (suspiciously even in hex).
  • arg5: A string; either "Console" (for fragment scripts) or the file name of the "compiled" VBScript script in AppData\Local\Temp.

Now all this is mainly in order to show what a brilliant person I am, but also serves a background to the real question:

Is there a way to force a cleanup or reset so that the JScript fragments can be run multiple times through the API?

I can see nothing in the API itself, and I've found nothing in the temp directories (and EA's three temp files do not get modified during a generation run), but there's got to be something somewhere that's left over from the first run and then not reset until a new session is established.
"New session" means restarting EA. Reloading the project doesn't resolve the issue, neither does closing and re-opening it.


It would also appear that the behavior when using a Document Script fragment (where the script returns RTF) is similar, but worse: there running the generation through the API fails every time, but it does work when running it through the GUI.
However, I haven't analyzed this in any detail.

And finally, this is all in 13.5. We will upgrade in the next few weeks, but I need to have this document generation done before that.


/Uffe

6
Hi all,


I'm on 13.5, but we'll upgrade in a few weeks.

I'm working on an MDG Technology which includes stereotypes where I use a shape script to decorate elements with images, which are included in the technology. They were imported into the MDG project as PNG, and render correctly in diagrams.

However, when I generate a document, they get black backgrounds.

Some images are monochrome black + whatever background colour is in the image, so they turn out as plain black squares.
Other images have colour. Their foreground is unaffected, but they get the black background.
Both variants render correctly in diagrams, with transparent backgrounds.

I had noticed the same problem when copy/pasting from a diagram into MS Office, but I got rid of that by switching the clipboard format to Bitmap (instead of Metafile) in the preferences. But there's no corresponding option for document generation.

There is a Renderer option in Diagram -- Appearance, but it does not seem to affect document generation, or at least, none of the renderers resolve the issue. I've tried all six.

I get the same result whether I generate DOCX or PDF. RTF also yields the same result, but takes massive amounts of time.

For a document which contains one diagram and nothing else, where the diagram has 12 connectors (information flow) and 10 elements with images and 3 without, the DOCX weighs in at 40 MB and the RTF 80. (The PDF ends up at 500 K.)

A similar document where the diagram has no decoration images comes in at 110 K. The images are 20 KB.


Clearly there's something weird going on with images in shape scripts.

Is there anything I can do to fix the images?

Or is someone able to check if this is fixed in 15?
I've found no mention in the version histories.

Or -- last ditch -- is there a way of getting a diagram image into a generated document without using DocumentGenerator.DocumentDiagram()? There's no InsertImage() in the API.


Cheers,


/Uffe

7
General Board / 14.1 Beta: any schema changes
« on: August 15, 2018, 05:51:05 pm »
Hi all,

Are there any schema changes in the 14.1 beta?
I would assume not, but it's not clear from the beta page.

/Uffe

8
Hi all,

Is there a way to access constraints in an Element shape script?
The manual only lists constraint properties for connector scripts, and there's nothing on the query page that seems to refer to constraints.

TIA,


/Uffe

9
Hello,


This is in 13.5, but there's no mention of any relevant changes in the history for 14.

Let's I create a class with an attribute with an initial value.

Let's then say I create both an instance of that class, and another class which is a specialization of the first class.
I switch on presentation of inherited attributes for both the instance and the specialized class.

If I now override the attribute initializer in my specialized class, that overridden value is shown in the local attribute compartment of that class. Good.
But the same change is shown in the inherited attribute compartment. In other words, it now looks like the attribute in the general class has the same initial value as it does in the specialized class -- which it doesn't.

This isn't great, but semantically I suppose you could overlook it: there is only one initial value for any given attribute (since an instance cannot logically be initialized twice), so the presentation of the parent's initializer is more of a convenience. It'd be nice if it was right, but it's not crucial.

But now consider the same situation with an instance with a run state, which exhibits the same behaviour.

In my instance it now looks like the initial value is what I've put into the run state. This is definitely wrong. The initial value is a property of the classifier -- it cannot change with the run state, which is a property of the instance.

Or is there some obscure Jehova's Witness-style mangling of the UML standard that allows for this behaviour?


/Uffe

10
Bugs and Issues / Artifacts and attributes
« on: June 26, 2018, 08:51:41 pm »
Hi all,


I'm working in 13.5, but there's no mention of any changes to this behaviour in the release history for 14.

The properties dialog for an artifact does not include a "details" page, but the context menus in both the diagram and project browser allow me to open the attributes dialog, which allows me to create attributes in the normal way, with type, scope and initial value.

If I create an instance of this artifact, its type is reported as artifact (not object). In its diagram context menu, under "Features & Properties", there's an item "Override Attribute Initializers." When working with classes, this item does not appear for an instance but for a specialized class.

The same menu item for a class instance instead has the "Set Run State" item. This is what I would expect for an instance of an artifact as well. I can get that if I create an object and set its classifier to the artifact, but not by dropping the artifact onto a diagram -- that forces the creation of an artifact instance.

I should also point out that the "Override Attribute Initializers" item, when selected for an artifact instance, only yields an error message saying that the instance "has no attribute initializers to override." That makes sense if the attributes of artifacts are intended to work like the attributes of classes -- but why have the menu item there in the first place, only to have it flash an error message?

However, the weirdness doesn't end there. If I create another artifact (classifier) and draw a generalization from it to the previous one, the diagram context menu for the specialized artifact does not include the "Override Attribute initializers" item -- there's just the normal "Attributes" item.

If I switch on presentation of inherited attributes, the attributes from the general artifact are shown (with initial values) in both the specialized artifact and in the artifact instance.

So.

1) Artifacts can have attributes.
2) Generalizations can be drawn between artifacts.
3) Attributes are inherited between artifacts connected by a generalization.
4) An artifact's local attributes can be given initial values.
5) Initial values of an artifact's inherited attributes cannot be overridden.
6) An artifact instance, which is itself an artifact, cannot have a run state.
7) An artifact instance, which is itself an object, can have a run state.

Is this by design?


/Uffe

11
Bugs and Issues / Default connector line style
« on: June 21, 2018, 05:07:33 pm »
Hi all,

Is there a way to set the default connector line style in a diagram?
Say I want all future connectors to use Tree Style - Vertical, or Orthogonal - Square. Can I set that somewhere?

/Uffe

12
Suggestions and Requests / Package Indicator for Here Be Locks
« on: June 15, 2018, 08:49:28 pm »
Hi all,

User locks are indicated with blue exclamation marks for "locked by me" and red ones for "locked by someone else."
It would be useful to be able to see at any package whether something in it, but not the package itself, is locked by me or (less importantly) by someone else -- all the way up to the root node.

Maybe a smaller exclamation mark, maybe an italic one, maybe a paler one, maybe something else, but having some kind of indication would help a lot.


/Uffe

13
Bugs and Issues / Project browser auto-side-scroll
« on: June 14, 2018, 01:16:20 am »
Hey all,


13.5 on Windows 10, the auto-side-scrolling project browser is driving me up the freakin post. For a project with more depth and/or longer names than some trivial Mickey-Mouse example it's worse than useless.

Not sure if this is EA's fault or some Windows bullsh*t but it doesn't really matter. Point is, is there a way to switch it off?
Only remedy I've found is to widen the window till it covers half the screen. Meaning I can't see the diagrams.


/Uffe

14
Hi all,


Here's a left-field one.

When working with multiple projects and moving models between them, being able to quickly compare two instances of the same model is useful.

One way of doing this is to start two EA instances, undock the same window in both of them, align the two windows pixel-perfect one on top of the other, and then alt-tab between them looking for anything that "blinks". This is an obvious approach when working with diagrams, but really it works equally well with any type of window (properties, project browser, element browser...).

This type of visual comparison would be simplified by the ability to transparentifize the windows. That's a word. You could then just undock one, make it transparent and move it on top of the other, still-docked window; or you could undock both, make them both transparent, line them up and anything that shows up faint will only be present in one window, ie a difference.


/Uffe

15
Suggestions and Requests / Add location to Required MDG Technologies
« on: June 08, 2018, 09:45:31 pm »
Hi all,


The Required MDG Technologies feature is useful, but it requires that users have the same MDG Technology paths set up. This is no issue for built-in technologies, but for locally developed ones it can be.

Specifically, if I want to trial a newer version of an MDG Technology I deploy it to a different network share than the "release" one. I would like to be able to set up a project to use my "trial" version instead of the "release" one and simply point my trial team to that project, but I can't do that because the MDGRequire and MDGBlklist (in t_genopt) specify the technologies by ID, not by file name.

So if the location could be added, either by using the technology file's path or by adding a t_genopt option for the MDG search path, I could specify the technology and path in my trial project and everyone would have a smoother EA experience.


As an alternative, of course, if the "MDG Technologies" dialog, as well as the required/disabled technologies option, were made version-aware, that would be even better.

By that I mean that the respective dialogs should list every version of each MDG Technology they find and force the user to choose exactly one of each such group. The technologies would be identified by their IDs, and listed with their version IDs.


Yet another alternative would be to store the technology ID + version ID in t_genopt. That would be good enough, although of course it wouldn't resolve the case where two MDG Technology files have the same technology ID and version ID -- but really that's poor version control on the developer's part.


/Uffe

Pages: [1] 2 3 ... 22