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 ... 84
Bugs and Issues / Re: SysML Activity Diagram Control Flow
« on: June 18, 2018, 05:10:09 pm »
EA has traditionally allowed this anyway, but while reworking functionality for version 14 we decided that it was time to prevent it by default.

Thank you Simon, that will spare me a lot of "There are no Activities on an Activity Diagram!" lectures in the future. :)


Hear hear.


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.


Bugs and Issues / Re: Files on Sharepoint
« on: June 15, 2018, 05:31:12 pm »
Out of curiosity, and Alin, please don't read this as a workable alternative; what I said in my previous post holds and enterprise deployment means DBMS repositories, but:

An .eap file is basically an Access database with another extension.
When using it tries to create a temporary lock file, which sharepoint doesn't allow.

Does that apply to Firebird (.feap) as well? Or would it be possible to store a Firebird repository in SharePoint?


Bugs and Issues / Re: Files on Sharepoint
« on: June 15, 2018, 05:27:27 pm »
Hello Alin,

SharePoint is the way to go until we get to deploy EA as an Enterprise solution. The long term plan is to go Pro Cloud on premise, but before I get there I have to demonstrate it works...

Unless you're proposing to use external version control and individual project files for each team member (in which case SharePoint wouldn't make much sense anyway), .EAP files are not part of an enterprise deployment. If you don't understand what I mean by "external version control", then that just adds weight to my argument.

Set up a database instead. SQL Server is probably the best choice since you're on a Microsoft platform.

It also seems you're confused about EA's so-called cloud solution. Pro Cloud / WebEA is not a separate type of model repository, it's a different way to access an already existing repository.

In other words, Pro Cloud is not an alternative to an .EAP file. There has to be either an .EAP file or a database behind it. Nothing is stored "in the cloud": models are always located in a repository, and that's either a file or a database.

Go with a database. It is better in all respects than an .EAP file.


Suggestions and Requests / Re: Package Indicator for Baselines
« on: June 14, 2018, 09:58:31 pm »

Bugs and Issues / Re: Project browser auto-side-scroll
« on: June 14, 2018, 08:58:53 pm »
For reference, Ctrl + arrow keys can be used to scroll the project browser, whether or not there is a scroll bar visible.

Be aware though that EA also interprets Ctrl + up/down arrows as "move the selected element up/down within its package".

But I haven't noted any side effects with the Ctrl + left/right arrows, and those are the important ones. (PgUp/PgDn can be used to scroll the project browser vertically anyway.)


Bugs and Issues / Re: Project browser auto-side-scroll
« on: June 14, 2018, 06:59:44 pm »
Thanks guys. I can report the following on 1352.

Some visual styles have a horizontal scrollbar, and others don't.

I tried creating a list of those styles, but it turns out the style-switching function is buggy as all hell and the results are not reliable. In general, more recent styles do not have h-scrollbars, while older ones do -- but changing back and forth might cause it to disappear even in a style that had it a moment ago, and I've also seen double v-scrollbars appear. Funny stuff!

It also turns out that switching to a style does not cause the same behaviour as starting EA with that style set from last time.
So if you start with the Office XP style there's no auto-scroll, but if you've switched to it from another style that has auto-scroll it's there.

That works in reverse too. Start up in Office XP and switch to Studio 2013 -- no h-scrollbar, no auto-scroll.

So one of the bugs appears to be that the auto-scroll behaviour is not (re)set when changing visual styles. It's only set during startup.

Which means this is actually a have-the-cake-and-eat-it-too kind of bug that allows you to select auto-scroll separately from the visual style.

Since I find the auto-scroll so incredibly annoying, I think it should be selectable in the Visual Style dialog.
Failing that, that particular bug should not be fixed but be allowed to remain as a workaround.


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.


General Board / Re: different sets of Default Types
« on: June 13, 2018, 07:17:10 pm »
Hej Rolf,

I think I was wrong before, or maybe I was still looking at version 11. In 13.5 it's a bit better, though not quite there.

If you create an activity parameter, you must open the properties dialog for the parameter in order to access its Language property.
If you set it, the Type dropdown will contain the appropriate set of types -- but only if you open the dialog with the Language already set. If you change the Language and click Apply, the dropdown still contains the types from the old language.

For action pins, however, it still doesn't work. The Language property is not honoured.

But those are bugs. Using the Language property is the proper way to customize the set of available types, so provided the bugs are fixed you should be able to do what you want.

I've also checked, and the Language property is set correctly for activity parameters and action pins if you change the language with "Code Engineering -- Reset Options for This Package". That might help speed things up as far as activity parameters are concerned.

Operation parameters also obey the Language property (of the interface, there's no separate property for operations or their parameters).



General Board / Re: unchecked "Show Namespace" as default?
« on: June 13, 2018, 06:58:51 pm »

It appears that's not one of the properties you can set when defining your own diagram type, and I'm not aware of a tool option or project setting to do it either.

So looks like "no".



There's no property you can check to find a package's (or element's) depth, so the simple way is to write a subroutine in whatever language you're using that calculates it.


Suggestions and Requests / Re: Support LDAP within WebEA
« on: June 11, 2018, 09:14:43 pm »
+ 1

LDAP integration is often a minimum requirement for any enterprise-wide tool deployment.


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.


That's not really the question. The question is, shouldn't it be possible to specify MDG Technologies with greater accuracy, taking into account file location and/or version?

The fact that the file location doesn't apply to the "import" deployment option is beside the point. The "referenced file" deployment option is supported, and could be improved in the manner suggested.


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.


Pages: [1] 2 3 ... 84