15.2 scroll behavior

[qwerty]

I once again had to dig into 15.2. I noticed that using the triangles above/below the scroll bar behave odd. I can click once and it moves the view. But any further click is ignored. Only if I move the mouse pointer a little (or much) it again accepts a click. With 13.5 on the same machine that works just ok (each click is accepted). So, what is that? And how can I turn it into behaving normally?

q.

[MichaelJ]

Hi qwerty,


Your pain is shared by the utter astonishment at how simple elements in the product don't work as expected.  This bug was reported on 20 Jan. 2020 and video evidence provided to the team to show the scroll bars don't work. Precious time was wasted by performing personal QA testing on their behalf, with all Windows messages logged and sent as evidence (WM_MOUSEMOVE, SBM_GETSCROLLINFO, WM_PARENTNOTIFY etc.). It is clear (from analysis) that this bug is because the parent container area does not respond to scroll messages.

Issue ID: 20013953
Version: 15.1 (build 1525)
Has this issue been fixed in 15.2? No.

What is to be made of considering the company's poor track record in responding to bug fixes (over a year and still not addressed)? How is this product still viable? Methinks only one way is possible: price. They clearly save costs on hiring a QA team or ACTUAL coders who can write quality code, because customers will (un)willingly perform testing on the company's behalf. And what do you benefit from the time wasted? An improved product with evidence the bugs were addressed? A sense of accomplishment and contribution to the product's greater good? Customer's performing real-world testing and bug logging would not be half as painful IF the bugs were indeed addressed when raised.


However, let the attitude of the company towards customers' bug reports and usability concerns (and lack thereof) speak for itself.

[Geert Bellekens]

Does anyone use those buttons? I don't think I used those in years.
Indeed a very weird bug, but I can understand it gets "cosmetic" as priority and as such may never get fixed at all (since there are always more serious bugs to fix)

Geert

[qwerty]

Just ask yourself, Geert: is it less important for someone else if you don't use it? I use them regularly to scoll bits up and down. You should complain at Mikeysoft to remove these controls rather than to excuse people not implementing them correctly. I well understand your position being an EA reseller. But in that role I shall club you with a teaspoon until you cry. Out of that role I highly respect you. You know what I mean?

q.

[Geert Bellekens]

Just ask yourself, Geert: is it less important for someone else if you don't use it? I use them regularly to scoll bits up and down. You should complain at Mikeysoft to remove these controls rather than to excuse people not implementing them correctly. I well understand your position being an EA reseller. But in that role I shall club you with a teaspoon until you cry. Out of that role I highly respect you. You know what I mean?

q.

I'm not talking as a reseller but as a user and a consultant.

I have logged dozens of bugs the last year. All of them more important than this one.
The workarounds for this bug are
- move the mouse a little
- use the bars to move up and down
- use the scroll-wheel on your mouse

A lot of the bugs I reported don't have a workaround at all, and seriously hamper working with EA and/or mess with model data.

I would prefer Sparx to fix those bugs before they fix this one, which is a minor annoyance.

But of course you are in your right to think differently about this 

Geert

[MichaelJ]

Hi Geert, qwerty,

I agree with your statement that there are more important bugs to address.

However, the problem with scrollbars not working as expected is the impact on users and frustration levels. As qwerty correctly stated, just because one person does not use scrollbar arrows, does not imply ALL users should forgo scrollbar arrows. Using Sparx EA, customers must constantly accommodate for poor implementation found in the product ("The workaround for this bug are...."). Why must customers fight with Sparx EA to achieve results?


Well-built software products foster reasonable expectations to quickly and efficiently achieve results. Yet, Sparx EA ignores all reasonable conventions (for example, Windows design patterns UX patterns etc.) and follow their own path. For example, we can drag-drop from the Project Browser onto a canvas, but we cannot perform the same drag-drop from the Traceability window if the element is anything other than a UML class. The workaround? Sparx EA introduces a "Place Element in Diagram" context menu (in the Traceability window) because it seems, they are incapable to deliver the same, expected, functionality as Project Browser.

Broken. Frustrating.
Issue logged.
Issue ignored.


Windows products work according to set standards. Apple product too. A scroll bar is a scroll bar across both platforms. Not in Spax EA.


@Geert, @qwerty, I assume you're very familiar with the product, so, out of curiosity, how much time and effort have you wasted over the years finding workarounds because normal-use expectations have failed?

[qwerty]

Formerly I would have claimed the bigger amount to me (and it's a huge pile). Now being frustrated more and more I just gave up looking for workarounds. I just simply curse and try to resort to God being a good person (which I still sometimes doubt). So Geert is now Mr. Workaround, I guess.

q.

[Geert Bellekens]

So Geert is now Mr. Workaround, I guess.

q.

I guess so. As an EA consultant my livelihood depends on this product.
So whenever I find a bug I report it to Sparx, and try to find a workaround.
I however refuse to let these things mess up my good mood or make me bitter. I very much want to keep a positive attitude in life and work
There are a lot of things much more important than EA

I still believe EA is the best (least bad?) UML tool out there currently.

Geert

[qwerty]

It's not just the triangles. It's the whole scrollbar. My guess: the developer only uses a mouse which will always have tiny movements. I'm using a trackpad which does not add that jiggle and so I notice this wrong behavior. Basically it's the same as with most of the bugs: there's no QA at Sparx.

q.

[MichaelJ]

...Basically it's the same as with most of the bugs: there's no QA at Sparx.

Yip, agreed, over and over. the lack of internal testing BEFORE release is obvious by damaged expectations concerning Feature X: always delivered half-tested and half-implemented. EA scrollbars are a perfect example.

It is understandable that software has bugs; that is the nature of humans writing code. However, methinks Sparx is lumbered with a codebase as ancient as COBOL and a team too afraid to communicate with it. This explains why "fixes" in each release always address only one specific scenario, and disregard others. The team is either focused on more "high priority" money-generating concerns, OR every issue, bug and feature is low priority and "not serious", OR the developers just plain and simply cannot address the fix using an ancient programming tongue, like ADA.

Take, for example, this quote

Now that Tags are stereotype properties, it is self-inconsistent to NOT copy tags of the connectors when the [X] Copy Connectors checkbox is marked.

It's a beautiful example of how (clearly) no testing was done when implementing the use case for "Make Tags stereotyped properties". Otherwise, why should a paying customer need to state the obvious?

I very much want to keep a positive attitude in life and work
There are a lot of things much more important than EA

I still believe EA is the best (least bad?) UML tool out there currently.

Geert, you set a good example by remaining positive. Though, if you were not an EA consultant, would it be as easy to overlook annoyances of the "least bad" UML modelling tool :-)?

[Eve]

Are you talking about scrollbars for a particular window or all of them? I've tried in a number of places and been unable to reproduce a problem. One possible suggestion though, try a different visual style. On most the scroll bars are customized, but if you go back to Windows XP style (as an example) they revert back to the default Windows scrollbars.

It's a beautiful example of how (clearly) no testing was done when implementing the use case for "Make Tags stereotyped properties". Otherwise, why should a paying customer need to state the obvious?

Alternatively, it's a beautiful example of how things can be connected when there is no connection. There was no change in the way tags were treated or classified. All that changed was how the UI presented them to users. The use case was more along the lines of make the properties for profiled languages visible to users. Specifically for users who don't have a background in either Enterprise Architect or the ancient versions of UML where EA took that terminology from.

Tagged values on connectors should have been copied when copying the connectors regardless. I'm not aware of a bug report saying that they weren't. I sincerely hope that Paolo made that spurious connection only to make his bug report sound more serious, not that he had previously reported that they weren't copied and was told that they shouldn't be.

[qwerty]

Interesting. Changing from 2016 (preset) to XP made the scroil bars work normally. So, since EA "repaired" itself it can probably be said it's broken at the other end, right?

q.

[Paolo F Cantoni]

[SNIP]
Tagged values on connectors should have been copied when copying the connectors regardless. I'm not aware of a bug report saying that they weren't. I sincerely hope that Paolo made that spurious connection only to make his bug report sound more serious, not that he had previously reported that they weren't copied and was told that they shouldn't be.

We'll I made the important connection (spurious as maybe) because we now use stereotype MDG tags as properties and surface them as widgets on our items.  So when we used [Ctrl+Shift+V] it suddenly became obvious that something was wrong as the widgets disappeared!  Investigation showed the property tags were missing.  Since we've moved almost exclusively to MDG based tags, the "normal" tags not copying was not apparent.

Paolo

[Eve]

I feel like I'm being baited, so I'm going to play politician instead. I wouldn't use the words 'broken' or 'repaired'. I've merely given you another way to mitigate the issue that you are experiencing. At the same time, I've given a future developer a little more information about the issue and possibly strengthened the argument that it's a cosmetic issue.

[Geert Bellekens]

Geert, you set a good example by remaining positive. Though, if you were not an EA consultant, would it be as easy to overlook annoyances of the "least bad" UML modelling tool :-)?

I'm definitely not overlooking them. I keep sending bug reports to Sparx for everything I find (and try to find a workaround in the mean time)

Do I think Sparx should do a better job testing their product? YES
Do I enjoy doing unpaid QA work for Sparx Systems? NO
Do I think Sparx should have a better (public) issue handling process? YES, definitely!

But after all, it's only a tool, and not even close to the most important things in my life. 

Geert