V16 - Indication on the App that we are using 64-bit or 32-bit

[Paolo F Cantoni]

Now that we have two versions of EA 32-bit and 64-bit, could we have some indication (permanently visible) as to which version we are running?  For our part, we will need to run both 32-bit and 64-bit on the same machine as we upgrade our Add-Ins and we'll be swapping between instances as we test etc.

If this is agreed upon, perhaps we can also get the version number or build.

I guess the status bar might be a convenient location for this information.

Thoughts?

Paolo

[qwerty]

Would  be cool. Especially when I found out the hard way that the 64bit version did not run with my Python environment.

q.

[BobM]

When I did a POC I used Visual style on the x64 client to know if I was working in x64 or x32
Its fixed to the client



the result was that I made the feature request in order to color code the repository links using these application look settings (if anyone knows how that can be resolved I would be grateful)

[Paolo F Cantoni]

When I did a POC, I used Visual style on the x64 client to know if I was working in x64 or x32
It's fixed to the client



The result was that I made the feature request in order to color code the repository links using these application look settings (if anyone knows how that can be resolved, I would be grateful)

Intersting, I've done that in the past, but it's only a proxy for the real answer - the App telling you what it is.  I run across multiple machines and even have different icons for the two variants.  It took me a few weeks to realise I'd reversed the icons on one (of 5 machines).  There's NO substitution for the App self-identifying.

Paolo

[Eve]

There's NO substitution for the App self-identifying.

Which is why it's in the about window, along with everything else that you want it to self-identify. That's what it's for.

I could be wrong, but I don't think it's generally applicable for all users to have that information permanently displayed.

[Paolo F Cantoni]

There's NO substitution for the App self-identifying.

Which is why it's in the about window, along with everything else that you want it to self-identify. That's what it's for.

I could be wrong, but I don't think it's generally applicable for all users to display that information permanently.

I understand all that, but having it visible, but discreet, would still be useful.  Currently, some of our users are running 3 different instances on the same machine.  Some functionality works in v15, is broken in v16, and some only works in v16.  We're trying to use the bigger capacity of 64-bit, but our addins still require 32-bits.  The version and word length are displayed on the splash screen, so why not on the main screen?  The About Window is usually reserved for the "gory details".

Would it be so hard?
Paolo

[qwerty]

It's definitely not hard. However, Sparxians are more after shifting/renaming menus from release to release rather than listening to what their community demands. Grind your teeth.

q.

[Eve]

I understand all that

I don't think you do.

but having it visible, but discreet, would still be useful.

The discrete place that it's visible in every piece of software I can think of that's available for 32 and 64 bit is in the About dialog or equivalent.

Currently, some of our users are running 3 different instances on the same machine.

And I have every version since v4 including shortcuts to 6 different instances on my desktop.

We're trying to use the bigger capacity of 64-bit, but our addins still require 32-bits.

And if you were developing an add-in for Chrome and it was not working for the 64 bit edition would you expect Chrome to always display if it's 32 or 64 bit?

The version and word length are displayed on the splash screen, so why not on the main screen?

It's discrete.

The About Window is usually reserved for the "gory details".

That's exactly what the architecture is. Gory details.

Would it be so hard?

No, it's not hard. It just doesn't make sense.

[Sunshine]

I just use the visual styles to colour the 32-bit and 64-bit differently which I see was suggested earlier. If you look at MS Office it doesn't appear to have any indicator as to whether its 32-bit or 64-bit other than in the about the licence, so I guess that has set a precedent for all other windows apps

[Paolo F Cantoni]

I just use the visual styles to colour the 32-bit and 64-bit differently which I see was suggested earlier. If you look at MS Office it doesn't appear to have any indicator as to whether its 32-bit or 64-bit other than in the about the licence, so I guess that has set a precedent for all other windows apps

But, as we've discovered, you can only have ONE bitness per machine.  So the precedent isn't.
Also, When we tried to set visual styles, we found both bitnesses on the same machine ran the same style.  Was that not correct?

Paolo

[Paolo F Cantoni]

[SNIP]

I want the indication to be discreet; it's already discrete!   (as you point out)
And if you can have multiple bitnesses of Chrome on the same machine and execute simultaneously and you need to switch between them often, I WOULD expect them to indicate which one is which discretely.

Paolo

[DeBAAT]

Hai, I agree with the request.

Would it be possible to differentiate the colour of the icon shown in the taskbar and on the desktop?
This would be a great help at least until it doesn't matter anymore which version you use...

[Paolo F Cantoni]

Hai, I agree with the request.

Would it be possible to differentiate the colour of the icon shown in the taskbar and on the desktop?
This would be a great help, at least until it doesn't matter anymore which version you use...

We already do that, so we know which version and bitness we are starting, but unfortunately, EA doesn't pick them up for display on the active copy!  However, adding some adornments to the icon used as the "File" menu could be a good solution.  Say version at the bottom left, bitness at the top right?
Also, although we can use the visual style to indicate bitness, we can't use it to indicate version (ask me how I know  )

Paolo

[Eve]

Also, although we can use the visual style to indicate bitness, we can't use it to indicate version (ask me how I know  )

Because the visual style is specified by the registry and by default that isn't changed between versions?

Would you be interested in knowing that you can add a /regkey:EA152 or /regkey:EA160 as an argument to EA to do exactly that?

https://sparxsystems.com/enterprise_architect_user_guide/16.0/the_application_desktop/defaultsandusersettings.html

[Paolo F Cantoni]

Also, although we can use the visual style to indicate bitness, we can't use it to indicate version (ask me how I know  )

Because the visual style is specified by the registry and by default, that isn't changed between versions?

We knew that, but it is interesting how that same concept is not consistently applied by the Visual Workspace management process.  We have to move our Visual Workspace definitions manually for each version.

Would you be interested in knowing that you can add a /regkey:EA152 or /regkey:EA160 as an argument to EA to do precisely that?

https://sparxsystems.com/enterprise_architect_user_guide/16.0/the_application_desktop/defaultsandusersettings.html

Yes, we would be.  But I don't believe it solves the fundamental problem, but it DOES help!

Now, which of the two self-inconsistent mechanisms is used here?
When EA sees the /regkey:<value> first time, does it copy the existing keys into the new key and thereafter allow you to change the values for that specific version?  (a, perhaps, rational design)
Or do we have to guess which keys we need to copy (since the Help doesn't specify) and manage the registry ourselves? (what q might expect to be the case) 

It would be useful to know before we waste any significant amount of time using it.

Paolo