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.

Messages - skiwi

Pages: 1 ... 108 109 [110] 111 112 ... 116
Bugs and Issues / Re: Labels on data object hidden
« on: May 13, 2010, 07:18:55 am »
Prompt work from sparx support
Here's the problem: the shape script lookup for the main shape searches for stereotype without worrying what the extended metaclass is, but the lookup for the label shape searches for the stereotype and extension. It shouldn't make any difference, until somebody applies stereotypes to the wrong metaclass.

The fix is to make the main shape search stricter, which won't help you and will in fact remove the shape script from this one object - you will have to replace your stereotyped class with a stereotyped artifact. The fix is also likely to break a number of diagrams that are currently "wrong, but look how you want them to look".

Bugs and Issues / Re: Labels on data object hidden
« on: May 12, 2010, 02:13:14 pm »
Some interesting information from my support response (with minor rephrasing)

The BPMN profile extends the "Artifact" metaclass with the <DataObject> stereotype. It does not extend the "Class" metaclass. If the stereotype is applied to the wrong metaclass then the results will be undefined.

Trying applying the shape script associated with the DataObject stereotype to a variety of different metaclasses (including Artifact and Class) results in all showing their name in a label which can be hidden, and they all have a "Show Labels" command which brings the hidden label back. The fact that one is a class and one is an artifact does not appear to be the cause of the problem.

Bugs and Issues / Re: Labels on data object hidden
« on: May 11, 2010, 02:33:39 pm »
Reported as a bug under subject

Artifact Entity stereotyped as a dataobject behaves differently from class stereotyped as a dataobject

Bugs and Issues / Re: Labels on data object hidden
« on: May 11, 2010, 12:47:08 pm »

Spot the odd entity out?

It is quite bizarre that because it is a stereotyped class it did not show the name label.

Bugs and Issues / Re: Labels on data object hidden
« on: May 11, 2010, 11:59:30 am »
I deleted the entity from the diagram only, saved diagram, then dragged the entity back into the diagram.
Still the same.
I also tried changing the font and font colour just in case.
Also tried deleting the name, saving, and putting the name back.
Still does not appear on diagram.

Bugs and Issues / Re: Labels on data object hidden
« on: May 11, 2010, 10:00:02 am »
OK, on each data object I can use F2.
This brings the label up for editing.
But F2 does not work on this one data object.
I also tried bring to front, sent to back, also using tab and cursor keys to move to and select objects - but these don't move to or select labels.

Bugs and Issues / Re: Labels on data object hidden
« on: May 11, 2010, 08:58:54 am »
Thanks, here is the data object

not sure what you mean by "non blank label", but the object certainly has a name.

Bugs and Issues / Labels on data object hidden
« on: May 10, 2010, 02:09:52 pm »

I found it odd that data objects have a label (the name) that can be selected and moved (unlike the name on most entities, actually this is a nice feature).

You can also hide the labels (see image above).

Once hidden though, how do I get the label back?
Help tells me to go Appearance | Show labels
which would be fine if there was such an option.


Bugs and Issues / White space, new lines, in RTF templates
« on: March 05, 2010, 09:53:17 am »
In my quest to produce professional looking documents OOTB I have been trying to understand how the RTF generator turns a template into a word document.

This issue appears to be that the RTF document generator either inconsistently handles newlines, or does not generate them when it should.

I have a document template with some debugging output, viz (I have added the # symbol to note numbering)

[highlight]package >[/highlight]
# {Pkg.Name}
{Pkg.Notes} [highlight]diagram >[/highlight]
Figure {Diagram.Figure}: {Diagram.Name}
{Diagram.Notes} [highlight]< diagram[/highlight] p [highlight]element >[/highlight]
#.# {Element.Name}
{Element.Notes}[highlight]model document >[/highlight]
[highlight]< model document[/highlight] m [highlight]diagram >[/highlight]
Figure {Diagram.DiagramImg}
{Diagram.Figure}: {Diagram.Name}
[highlight]< diagram[/highlight] d [highlight]child elements >[/highlight]
[highlight]< child elements[/highlight]
[highlight]< element[/highlight] e [highlight]child packages >[/highlight]
[highlight]< child packages[/highlight]
[highlight]< package[/highlight]

debugging output is the letters o m d and e

It seems to me that where one has

[highlight]diagram >[/highlight]
Figure {Diagram.Figure}: {Diagram.Name}
{Diagram.Notes} [highlight]< diagram[/highlight]

and there is no content at all to place between the [highlight]codes [/highlight](in this case "[highlight]diagram>[/highlight]") no white space, or newlines should be inserted in the text.

It also seems to me that where one has

[highlight]element >[/highlight]
#.# {Element.Name}
{Element.Notes}[highlight]model document >[/highlight]
[highlight]< model document[/highlight] [highlight]diagram >[/highlight]
Figure {Diagram.DiagramImg}
{Diagram.Figure}: {Diagram.Name}
[highlight]< diagram[/highlight] [highlight]child elements >[/highlight]
[highlight]< child element[/highlight]s
[highlight]< element[/highlight]

that the new line after the "[highlight]element >[/highlight]"  should always be generated - because a heading will always be generated.

In my testing it seems that this is not the case.
In some cases I have the heading being appended to the previous text, and thus the heading style wrongly applied.

There are other funnies too
When trying to place more than one code on a line (to reduce the number of empty lines that can be generated a space MUST be applied between the codes, viz [highlight]< diagram[/highlight] [highlight]child elements >[/highlight]

Also when working with the template, and inserting new sections existing codes can be overwritten, corrupting the template.
Surely this is just sloppy development and testing.

I have also tried [highlight]model document >[/highlight] [highlight]< model document[/highlight] and don't seem to have consistency between the generation of the first element encountered, and the child elements and child packages.

I would find a clear exposition of the rules relating to the insertion of content into the template, and the way while space and particularly newlines are handled.

Let me be clear about how I would like it to work.

I don't want to see empty lines created (ie multiple new lines with no content).
I want to handle all white space through document styles.
It would of course be better if the RTF editor handled paragraph formatting in a much better way, eg spacing before and after, keep lines together, keep with next, widow/orphan, but these seem to get lost in translation between normal.rtf and EA.

The RTF editor should alter content to the extent that for notes and linked documents the there should be one, and only one newline, no matter if the note or linked document has zero, two, or more newlines terminating it exactly one should be placed in the generated document (leading new lines and embedded new lines should be taken as is).

The generated document

Bugs and Issues / Re: Just how do those EAP files grow anyways?
« on: January 11, 2010, 06:48:28 am »
You can also (and more easily) use, if you have it, MS access to repair and compact .eap files.

Bugs and Issues / Repeating table headers in RTF documents
« on: November 30, 2009, 07:42:00 am »
We have had an issue for several versions where when using tables in generated documents either
  • the header row was repeated for every data row, or
  • each row had differing width cells
It looks like many tables were being generated instead of one.

We reported this recently, and I am pleased to say that we have been told a fix might be available as soon as 851

Bugs and Issues / Re: Link to element feature
« on: January 13, 2010, 08:45:11 am »
ANother example where perhaps layour could be improved

Note the two (blue) tables where the connector is at the top/bottom,
presumably because of the distance above/below the common table to the left.
Note also that all blue tables are in the same order as the feature columns to which the elements are linked.

Bugs and Issues / Re: Link to element feature
« on: January 12, 2010, 12:19:47 pm »
Thank, yes I use mainly autorouting (I like the perpendicular layout).
I did try custom as well (leftmost connector in original image).

I have reported this issue, and had it reproduced and accepted as a bug.

Bugs and Issues / Re: Link to element feature
« on: January 12, 2010, 11:30:31 am »
I duplicated this as a package I could give to EA to help replicate the problem.

Here is another picture showing connectors that don't work well.

As for the selection point offset bug (which I have been frustrated by often before), to paraphrase
" I've clicked everywhere man, I've clicked everywhere
I've clicked the line itself man, I've clicked the crows feet too, man
Of clicking I've had my share man, I've clicked everywhere
I've clicked near and far, left and right, up and down, slow and quick, I've clicked everywhere man"

Bugs and Issues / Re: Link to element feature
« on: January 11, 2010, 01:23:36 pm »
Hmmm, the Diagram | Save Image has a bug, it truncated part of the diagram. See the screen capture

Note that the Meshblock to Address connector is not selectable any more.
The AddressHistory MeshblockHistory can only be selected at the very end where the feature is not enabled.

Currently I can't turn the feature off as I can't select the these two connectors where I need to to gain access to the context menu.

Pages: 1 ... 108 109 [110] 111 112 ... 116