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

Pages: 1 2 [3] 4 5 ... 81
31
General Board / Re: 'Link' Connector type - did I imagine it ?
« on: April 17, 2018, 12:12:46 am »
Hi Ian,

There are Links, and you can connect two Objects with one, in 13.5.

/Uffe

32
... any chance of a RegisterRASAsset() call making an appearance as well...?

33
Great, thanks! :)

/U

34
Will do. I'm still waiting for Sparx to get back to me about the use of their logo, but I've given them a poke and we'll see what happens.

Meantime, there's always user documentation to write. :-\

/Uffe

35
Bugs and Issues / No API documentation for Repository.ImportRASAsset()
« on: April 13, 2018, 06:34:55 pm »
Hi all,

There is no documentation in the user guide for the automation function Repository.ImportRASAsset(), which was introduced in 1308.

According to EA's VBScript IntelliSense it takes eight string parameters, which takes a bit more effort to work out through trial and error than I would like to spend.

Reported.


/Uffe

36
Hello,


The operation which a CallOperation action calls is stored as the action's classifier, enabling you to locate the operation from the action (in a diagram) by hitting Ctrl-Alt-G.

What complicates matters is that EA actually stores an element's classifier in two ways in the database -- t_object.Classifier holds the classifier's element ID, which is an integer, and t_object.Classifier_guid holds its GUID, which is a string.
Only t_object.Classifier is reflected in the API (Element.ClassifierID), and it's only valid for elements whose classifier is another element (eg Objects). t_object.Classifier_guid, which is used for CallOperation actions, cannot be retrieved through the API.

Instead, you have to go to the database. To retrieve the operation, do something like

Code: (VBScript) [Select]
queryResult = Repository.SQLQuery("select Classifier_guid from t_object where Object_ID=" & element.ElementID)

' You'll need to parse the returned XML text here. A quick and dirty way in this case, since you know
' there should be exactly one result and the tags are always the same, is a hard-coded Mid() call.

methodGuid = Mid(queryResult, 120, 38)

method = Repository.GetMethodByGuid(methodGuid)

HTH,


/Uffe

37
Bugs and Issues / Change: inconsistent details views
« on: April 11, 2018, 12:39:00 am »
Hi all,


I've spotted an inconsistency between the two details views for a Change, specifically with the Version property. I assume the behaviour is the same for other maintenance types.

The Changes window is a non-modal window which has the list of Changes for an element along with a details view which (NB) contains all the properties for a Change.1

You can also use the Element Browser, which is also a non-modal window with a tree view in which all maintenance items (and a bunch of other stuff) is displayed with just some basic info.
From the Element Browser you can double-click a Change to open a modal window titled "Change details for <element type>: <element name>" which (NB) contains all the properties for a Change.1

Here's my thing.

If you create a Change from the Changes window, it's given a default Version. A little cryptic, and not related to what's in the element's Version property, but whatever, it's there and you can change it to whatever you want.
You can even clear that property, and save the Change. The empty string is saved in the database.

But here's where it gets weird.

If I open up the Change Details window, the empty Version is replaced with a new Version on the same form as the default. The database has not changed at this point, but the Apply and OK buttons are disabled even though the dialog contents do not match the database.

If I close the Change Details window without making any changes, I don't get a confirmation prompt.

If I open it up again, there is a new generated Version filled in.

So in other words the Changes window allows empty Versions, but the Change Details window does not.

Reported.


/Uffe


1There's actually one column in the t_objectproblems table, Severity, which is not shown. But it's not in either of these windows, so it is consistent.

38
Aha! Got it!

For "Notes Window", read "Summary View".

The Summary View shows some basic info from whatever you've selected in wherever you've selected it.
So if you select something in the project browser, Summary View shows object type, name, notes and some other stuff depending on the object type.
If you select something in a maintenance window, Summary View shows maintenance type, name, version, status, requested by, completed by, description and history.

JAUGB.

/Uffe

39
Yeah, but that's not it. That window (Changes in this case; there's actually a different identical-looking window for each maintenance type) is the one the linked user guide page is for, which says that the description (from the Changes window) shows up in the Notes window.

Which it doesn't.

/U

40
Hi all,


According to the user guide, the Description field of a Maintenance Item should be shown but not editable in the Notes window.

I don't see anything in the notes window, whether I select the element that has an associated maintenance item in the project browser or a diagram, or even if I select the maintenance item itself in the element browser.

Is there a configuration I'm missing?

Cheers,


/Uffe

41
General Board / Re: how to merge two project files of EA
« on: April 10, 2018, 06:00:25 pm »
Hello,


To clarify: in order to be able to merge changes, you must have decided beforehand that you will want to do that.

The two modellers must have worked in the same package (by GUID, not by name) in two different projects. Otherwise, the only option is to manually redo the changes from one model in the other.
Working in the same package in two different projects can be achieved in a few different ways; using copies of the same project, or external version control, or baselines, or reusable assets. (There's also a feature called "time-aware modelling", but it looks like you haven't been using that.)

If you haven't used any of these, you can't merge changes after the fact because the two modellers haven't been making changes to the same package.

That said, you're talking about two different features which are to be merged into one. That's not what's usually referred to as merging. That's more like restructuring a project to combine two different models, or parts of models, into one.

If that's what you're after then that is definitely a manual job. It's not two versions of the same thing that need merging, but two different things which are to be combined -- and there's no way of doing that that doesn't require interpretation of the model contents, ie actual human understanding.


/Uffe

42
If you can live with stereotyping them, here's a shape script to show the direction of an activity parameter:
Code: (shape script) [Select]
shape main {
h_align = "center";
v_align = "center";

DrawParentShape();
Print("#direction#");
}

And for action pin:
Code: (shape script) [Select]
shape main {
h_align = "center";
v_align = "center";

DrawParentShape();

if (HasProperty("kind", "input")) {
Print("i");
} else if (HasProperty("kind", "output")) {
Print("o");
}
}

(The pin is too small to show the whole word.)

/Uffe

43
Hi Peter,


In 1352, if you've got an Action Pin which is slaved to an Activity Parameter, you can see (but not edit) its Behavior, and you can pick which Parameter you want to slave the Pin to.

If you've done that and you then change the Pin's Classifier (Ctrl-L), this also changes the Type of the corresponding Activity Parameter. :o
Conversely, if you modify the Activity Parameter's Type, any slaved Action Pins are updated.

In other words, I can't reproduce what you've got with a classifier A, type B and parameter type C. Changing the classifier changes the parameter type.

As you know, I asked a Pin-related question of my own a week or two ago. I turned that into a feature request, which I copied in a post here.
Basically, I want the Pin's properties to be non-editable when it is slaved to an Activity (or really any Behavior) Parameter.

Feel free to agree with me. :)


/Uffe

44
Hi all,

Following on from my earlier Bugs & Issues post, I sent the following feature request to Sparx on March 28. I haven't heard back yet, but will update this post when and if.

/Uffe


1) For action pins which do not have a defined Argument but do have a defined Type, provided the type is a classifier, the classifier's tagged values should be included in the pin's extended tagged values.
This is how activity parameters behave.

2) For action pins which have a defined Argument, it should not be possible to edit the Name, Type, Multiplicity, Kind, or its Stream, Control Type or Exception properties.
These properties should all be slaved to the argument's corresponding properties.

3) If an action pin has a defined Argument, and that argument has the Fixed Value property set, it should not be possible to edit the pin's Value.

4) When creating an action pin based on an activity parameter, the pin's Value should be set to the parameter's Default Value, if any.

5) When creating an action pin based on an activity parameter, the pin's Kind should be set based on the parameter's Direction as follows:
in => in
out => out
return => out
inout => this should result in two pins, one in and one out, with otherwise identical properties.

6) When shown in diagrams, an action pin label should contain the following based on which of the pin's properties are set:
Name and Value => "name = value" (Type omitted if set)
Name, no Value => "name : type"
Value, no Name => "value : type"

45
Hey guys,


Just FYI I've been working on a Visual Studio extension for EA Add-Ins, which I'm hoping to release in the next couple of weeks.

It's working, but I've asked Sparx for permission to use a version of their logo in an icon and I haven't heard back yet.
(If they say no, I'll just release it with a different icon -- there's no other Sparx IP in it.)

This is a Visual Studio extension and as such it is integrated into Studio. No copying, no fiddling, just hit New Project, fill in the details and you've got yourself a brand spanking new Add-In solution.
Once the solution's been created (takes a couple of seconds), you can build it immediately. If you run the resulting MSI installer, EA will pick up the Add-In (meaning it shows up in the Manage Add-Ins dialog) but of course it doesn't do anything because you haven't put any code in. :)

The template gives you all the event handlers, but nothing else: no menu handler, no About box, nothing.
This is because I don't want to make assumptions about or place constraints on how you structure your code or what features your Add-In should provide.

It's also not intended to help you understand how Add-In development works, or for that matter the intricacies of the Windows installer. It's a productivity tool for Add-In builders like myself.

If all goes to plan, this extension will be available through the Visual Studio Marketplace by the end of the month.


/Uffe

Pages: 1 2 [3] 4 5 ... 81