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 - MaXyM

Pages: [1] 2 3
I guess you better cast both fields to string to compare them instead of trying to cast it to a number.

Casting to empty string is in general wrong idea (even if this time it might work)
It's better to use proper syntax for comparing values incl. NULLs. For example
Code: [Select]
It's worth to remember that in most cases/SQL dialects any operation with NULL (including boolean evaluation) gives NULL. And then NULL is never casted to boolean. So even NULL = NULL condition is not TRUE (but it's not FALSE too)

In fact this is great subject to rise during recruitment
I love that ;)

Automation Interface, Add-Ins and Tools / Re: DiagramLink and Connectors
« on: December 06, 2017, 07:31:02 pm »
Just out of curiosity. If I set color using link.LineColor, how can user affect the color using GUI?

BTW I ended up with setting TaggedValue instead of color, and using Legend feature. It seems to be more flexible solution.

Automation Interface, Add-Ins and Tools / Re: DiagramLink and Connectors
« on: December 05, 2017, 07:22:48 pm »
@querty at the beginning I was looking for way how to change connector color in relation to connector labels (Actually how to find related connector having diagramlink). The rest are just findings I wanted to share with community (because I've found no information about it)

@Simon thanx for answer. I supposed this is multi-level. But I didn't know there is possibility to set a color of connector (actually diagramlink), which cannot be overriden by diagram specific option available in GUI (Appearance option). Also I found no option in GUI to change colour of the diagramlink. Appearance option refers to connector.color.

Automation Interface, Add-Ins and Tools / Re: DiagramLink and Connectors
« on: December 05, 2017, 10:08:21 am »
Bravo... your conclusion is perfect. I hope the name of this subforum didn't help you much ;)

Actually I figured it out on my own by analysing Geert's code from:

Code: [Select]
connector = Repository.GetConnectorByID(link.ConnectorID); // where link comes from diagram.DiagramLinks
if (selectedConnector.ClientEnd.Role.match('^FK_') || selectedConnector.SupplierEnd.Role.match('^FK_'))
    connector.Color = 255; // for red

What is really interesting, that there are 2 methods of how to set color. 
The first one I tries was
Code: [Select]
link.LineColour. But this way overwrites possibility to change this colour by using Appearance option from context menu over particular connector. In this case the color chooser shows the last color set by this tool (not current one show on diagram). Color tool just doesn't work until we set link.LineColour to -1. Then Appearance takes control over line color again.

Automation Interface, Add-Ins and Tools / DiagramLink and Connectors
« on: December 05, 2017, 01:48:31 am »
Hello guys
I spent half a day searching for information but at the end I have to ask for it.
I need to change color of DiagramLink in relation to labels. But:

1. don't know how to get labels directly from DiagramLink
2. don't know how to find Connector which is represented by DiagramLink

BTW I found funny thing trying to set LineColor (attribute of DiagramLink). It seems to be BGR instead of RGB. So 255 is red (hex 00 00 FF), respectively blue is 16711680 (hex FF 00 00).

with regards

BTW what's the reason to have multiple items representing the same element on a diagram?

As db programmer I can suggest to stay away from UML modeling tools for database modelling as long as you can.
Why? Because those tools are not dedicated this task, therefore are very limited regarding database-wise features. Instead, they implement db support deriving most features from class diagrams and adding some minimal coverage needed by db.

Specialized tools do their best to cover features and requirements for various databases including specific differences between dbms' (like index required for FK in case of mysql, which is not mandatory in other dbms), making modelling just easier and faster.

Simple example: In each db modelling tool I know, foreign key is created just by dragging and dropping primary key onto another table. Yet few years ago, in EA you had to manually: create column for FK, setup the same datatype, create relationship between 2 columns, name it, create index if needed by particular DBMS etc.
Ussually UML tools are also late regarding features released with recent database versions.

It's true, that some features finally met UML tools. But are still light years behind soft like CaseStudio (almost 20 years ago), ToadDataModeler, PowerDesigner and many more. yeah... and limits db reverse engineering to more expensive licenses... LOL.
but even with all those improvements you are going to struggle with tools like EA. Below simple example from EA13.5. Reported already, receiving nothing but note they will look at this later but it's not considered as bug.
Try to reverse engineer tables from more schemas. You are end up with all tables put in single package called tables. Unfortunately schema names will be not shown (actually are stored in tag value). So basically you lost visual information about schema - you can see all tables from various schamas mixed together.  OK... I bet you will attempt move tables into subpackages named by schemas and try to import schema by schema. But then EA is not able to reverse engineer FKs between tables which are located in other packages than mentioned Tables package. Moreover, RE tool shows the missing FKs and offers synchronize action. But cannot do that. And it is not A BUG by Sparx definition.

But of course there are cases when going for UML tool is justified. One of them is a need of mapping other part of architecture (components or even business needs/requirements) onto database objects. If you don't need that, if you want just to model database without taking care about the rest of system look for dedicated software. Otherwise you will end up struggling with operations/features which you expecting to be available but in fact there are not over here.

General Board / Re: Communication Path not traceable
« on: October 03, 2017, 02:44:46 am »
Hi all
Have to reply to myself.
I filed bug report and get following answer:

Unfortunately this is currently an expected limitation of the relationship matrix.
I will submit a feature request on your behalf so that the ability to include Communication Paths (and ideally all connector types) is considered for implementation in a future release.

BTW it seems to be default answer for each reported bug.

I performed some searches and found it has been reported on this forum multiple times. And they (if Simon bellows to "them") had expressed a desire of improvement.,24167.msg196420.html#msg196420
But it was in 2012....

Bugs and Issues / Re: Values of attributes always truncated
« on: September 27, 2017, 12:25:08 am »
Hello all.
Just FYI: Sparx has answered that it is not a bug. However they have submitted a feature request for this.
Don't get why the issue is not considered as bug, since the element presentation is not aligned with compartment settings. At least I have some hope getting it in future.

General Board / Re: Dynamic list of dependencies
« on: September 21, 2017, 09:03:43 pm »
Yes, this is exactly what I would like to achieve.
Thanks you for an idea of using script.
You are right, adding single connection requires similar effort to running the script. On the other hand, in case some relation hasn't been added in past, the script might provide added value.

General Board / Dynamic list of dependencies
« on: September 21, 2017, 07:37:00 pm »
Let's say I have an application component which have to communicate with all (dozens) db servers in my network. Components which represent db servers are located in packages.
I would like to save manual work (which is error prone) of adding connections while adding new servers
On the other hand I need to maintain traceability between the component and servers.

I could imagine some element which generates list of elements based on SQL. Something like ModelView but it doesn't provide traceability. Could you please suggest me some way? Maybe I'm trying to manage it from wrong end?

Bugs and Issues / Values of attributes always truncated
« on: September 21, 2017, 01:32:29 am »
Hello guys.
Please look at image below.
You can see 2 elements. GenericServer Node element on the left side and it's instance on the right.
Both are node type elements without stereotype.

Attribute values are truncated. Doesn't matter it is a classifier or an instance.
Please note that settings available in Features and Compartment Visibility simply doesn't work in this case, whatever I set.

On the other hand, RunState values are not truncated. Unfortunately Feature and Compartment settings are not applied to this area also. Longer strings protrudes out of the shape.

Do you have any idea what happens and how to cope with that?
Worth to say I would like to see attributes not truncated, or truncated only if they really don't fit the shape.
Also since duplicated information is waste of space I would like to hide one or another data (RunState ones or inherited from classifier). I know I can hide RunState, but then I can see truncated values. I can hide Classifier attributes, and yes, this is how I'm doing it right now, but this way I cannot see datatypes as well as attributes which aren't set in RunState (incl attributes set in classifier only)


Exactly. Just for sake of sharing experience:
You noted that connector.Direction has priority. From my experience modyfying its value does nothing. However probably EA uses this value to draw connectors.
The value is updated in response of changing other rrelated attributes (as you mentioned).

For example:
In case of need to modify "Destination -> Source" direction, I had to use connector.(SuplierEnd or ClientEnd).Navigable. It makes .Direction updated, too.

There is very similar case for setting Shared vs Composite aggregation. Instead of changing value of connector.SubType, I had to set conn.(SuplierEnd or ClientEnd).Aggregation.

I believe there might be even more such glitches.

Best regards

I wonder too ;)
But you are right, I'm probably infected by issues I recently fought with. Issues which are definitely connected with the mentioned bug.
The finding reported in this thread has been found while debugging those issues.

One way or another, it very weird behaviour.

I believe it's related to a bug reported 10 years ago!
Fortunately there is a workaround existing:

I've checked it on my end and can confirm that the setting affects direction as expected.

Pages: [1] 2 3