UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Ribbons Getting Jumbled, Access 2013    
 
   
ptaussie
post Jul 15 2018, 11:01 PM
Post#1



Posts: 5
Joined: 10-July 18



Hello, i'm new here but signed up so i can put this question out to the experts as i cant find anything related anywhere.
i have a series of databases that have just been converted from Access 2003 to Access 2013. Around 30 users use these databases on a remote desktop setup that runs runtime Access. Each database has a couple of customised ribbons, for report viewing, list viewing etc.
One particular user in the quoting database (the user with the most varied use) during her daily activities will find her menus work fine for a while but 'go strange' on her through the day. she has since found another couple of users who also report the same issue.
The issue is that sometimes some of her buttons will disappear, and others when clicked will activate the incorrect function. eg clicking 'Page Setup' might open the Print Dialog or 'Close Print Preview' might activate the Filter or Sort functions, with the matching pop-up hover-tip (i have screen shots).
I cannot reproduce it on my computer, but have tried all sorts, including removing the custom button but have found nothing has helped her. In some it seems to me that it could be related to the context-sensitive buttons that become disabled in certain scenarios because it is like the functions get moved x amount of buttons left depending on how many are disabled.
She can close the db and re-open and it is fine again but it just makes no sense...
Any suggestions would be greatly appreciated.
below is code

FORM VIEW RIBBON:
<customUI xmlns="http://schemas.microsoft.com/office/2009/07/customui">
<ribbon startFromScratch="true">
<tabs>
<tab id="QF" label="Quotes" visible="true">
<group id="QFSearchSort" label="Sort, Filter and Preview">
<box id="QFBox" boxStyle="horizontal">
<button idMso="FindDialog" size="large" visible="true" />
<toggleButton idMso="SortUp" size="large" visible="true" />
<toggleButton idMso="SortDown" size="large" visible="true" />
<button idMso="SortRemoveAllSorts" size="large" visible="true" />
<button idMso="PrintDialogAccess" size="large" visible="true" />
<button idMso="PageSetupDialog" size="large" visible="true" />
<button idMso="PublishToPdfOrEdoc" size="large" visible="true" />
<button id="XLExport" label="Export To Excel" imageMso="ExportExcel" enabled="true" onAction= "=MyXL()" size="large" visible="true" />
<button id="PriceCheck" imageMso="AccountingFormat" label="Price Check" enabled="true" onAction= "=PCheck()" size="large" visible="true" />
<button idMso="PrintPreviewClose" size="large" visible="true" />
</box>
</group>
</tab>
</tabs>
</ribbon>
</customUI>

REPORT VIEW RIBBON:
<customUI xmlns="http://schemas.microsoft.com/office/2009/07/customui">
<ribbon startFromScratch="true">
<tabs>
<tab id="QR" label="Quotes" visible="true">
<group id="QRSearchSort" label="Sort, Filter and Preview">
<box id="QRbox" boxStyle="horizontal">
<button idMso="FindDialog" size="large" visible="true" />
<button idMso="PrintDialogAccess" size="large" visible="true" />
<button idMso="PageSetupDialog" size="large" visible="true" />
<button idMso="PublishToPdfOrEdoc" size="large" visible="true" />
<button id="XLExport" label="Export To Excel" imageMso="ExportExcel" enabled="true" onAction= "=MyXL()" size="large" visible="true" />
<button id="PriceCheck" imageMso="AccountingFormat" label="Price Check" enabled="true" onAction= "=PCheck()" size="large" visible="true" />
<button idMso="PrintPreviewClose" size="large" visible="true" />
</box>
</group>
</tab>
</tabs>
</ribbon>
</customUI>
Go to the top of the page
 
JonSmith
post Jul 16 2018, 02:22 AM
Post#2



Posts: 3,958
Joined: 19-October 10



So there is some mixed terminology here.
You mention menu's, which are a 2003 thing, and ribbons, which are a 2007 thing. Now when you use 'menu's in 2007 and higher they appear as a ribbon in the 'Addin's tab.
It seems like you converted all those 2003 menus into the newer XML ribbon format and thats now what you are having problems with. can you please confirm that is the case?

I see nothing wrong with your XML code. It sounds like its not the buttons that use callbacks you are struggling with but rather the ones that based on built in commands (the idMso ones?).

If so thats very strange and not something I've come across before. You mention the buttons get disabled and moved around but I can't see anywhere in your code where that happens? None of the buttons have any enabled or visible callbacks?
It would be really good if you can demonstrate this behaviour to us. I know you said you cannot repeat it but you can get the user to record it.
In the start menu search for 'Problem Steps Recorder' or psr.exe
That should allow you record the mixed up buttons and it'll be really sure that nothing dumb like pressing the wrong button is the issue.

JS
Go to the top of the page
 
ptaussie
post Jul 17 2018, 06:42 PM
Post#3



Posts: 5
Joined: 10-July 18



Thanks for your reply Jon. Sorry about the mixed terms... yes now we are in MS Access 2013 we are dealing with ribbons that i have added via the USysRibbons table in the XML below. Thanks for checking through the code, it all helps to confirm that it should work ok. As mentioned, most people are using this perfectly fine and even the users i mentioned are using it ok for some of the time. i just don't know what is triggering the 'strangeness' and why it is only a small group of people either experiencing it or complaining about it.

There is no code to disable buttons or move them around, there should be nothing there to tweak them on the fly. When i say the buttons become disabled, what i mean is that the become 'greyed out' when not relevant eg... "Close Print Preview" becomes disabled when not in report preview screen, "Find" becomes disabled on report preview screen, "Remove Sort" becomes disabled when no sort is applied etc. I have a couple of different ribbons, one i have specified in all the reports, and the others i have set as the standard one through the Options menu. I mainly did this because i was suspicious the issue was coming from these buttons becoming disabled so i tried to make them more specific, however i havent been able to eliminate it completely, as some of them are more context sensitive than others. i might be best once i sort this out to standardize it again and just have one menu for the database.

I have (hopefully) attached here a couple of screenshots showing the menus as the user hovers over them. as you can see the tool-tips do not correspond to the button and when clicked, the action that will occur is the one indicated in the tool-tip. These screen shots are from a little while ago and i might have tweaked the menus since ( i have tried all sorts), but it will hopefully give you an idea of what is happening.

I really appreciate your help with this.

Attached File  menus.jpg ( 50.11K )Number of downloads: 9



Go to the top of the page
 
isladogs
post Jul 18 2018, 02:24 AM
Post#4



Posts: 656
Joined: 4-June 18
From: Somerset, UK


At a quick glance, it seems that the tooltips shown are shifted to the right in each case by the number of disabled commands (4)
Are you using a count system to determine which tooltip is displayed?
Go to the top of the page
 
JonSmith
post Jul 18 2018, 02:37 AM
Post#5



Posts: 3,958
Joined: 19-October 10



So what happens if you press the button in the last screenshot? That supposedly points to a close print preview, which is greyed out....


As I mentioned before, can you please use the Problem Steps Recorder, the reason I ask it because it can do stuff like what I attached. I am wondering if it is registering the click as pressing the right button but it does the wrong behavior or if it registers the click as a different button.

@isladogs
QUOTE
Are you using a count system to determine which tooltip is displayed?

Those are built in commands, as indicated by the idMso (only built in commands have the idMso tag available, user created ones have an id tag). The tooltips are not handled in the xml nor any callbacks, the tooltips can be changed somewhat with callbacks but thats not the case here.
This are the tool tips that Access has built in, which makes it weirder that they are shift.


@ptaussie
This is a total guess, but mabe add a few more groups in your XML, split the controls so the 'disabled' ones are in their own group. Perhaps that separation will help Access keep track of them better?


Attached File(s)
Attached File  Capture.JPG ( 115.43K )Number of downloads: 11
 
Go to the top of the page
 
isladogs
post Jul 18 2018, 03:24 AM
Post#6



Posts: 656
Joined: 4-June 18
From: Somerset, UK


Also have you tried specifying the screentip in the ribbon XML as below:

Attached File  RibbonXML.PNG ( 30.02K )Number of downloads: 6


Attached File  RibbonTooltip.PNG ( 29.72K )Number of downloads: 1
Go to the top of the page
 
ptaussie
post Jul 20 2018, 02:04 AM
Post#7



Posts: 5
Joined: 10-July 18



Thanks for your replies.

I wasnt aware of PSR before you mentioned, so it is good to know. I have done a recording and will attach it here. Some of the buttons have disappeared and the remaining ones 'mostly' have taken on the functions of the ones that should be there, with the exception that there are two Sort Descending buttons next to each other.

Sorry i got a bit carried away with the recording so have edited a lot out to make it simple and exclude company info. All these screen should be using the FORM menu, not REPORT menu (though it actually looks like the report menu in this instance). Hope there is enough info here.

When this happens, the user has discovered if she clicks the file menu, hits ESC to cancel the file menu then the menus return to their correct configuration. (as per last couple of steps)

Re the tooltips, they are just the easiest way to demonstrate and not so much the issue as the button performing the incorrect function.

Thanks again

Attached File  Recording_20180720_1306.zip ( 1.76MB )Number of downloads: 24




Go to the top of the page
 
JonSmith
post Jul 20 2018, 02:31 AM
Post#8



Posts: 3,958
Joined: 19-October 10



Great, thats interesting results.
Its a shame we didn't see a postive button press after the escape behavior, it would be have interesting to see if any of the elements in play (listed at the bottom for each step) had changed.

So the ESC behaviour, maybe that is invalidating the ribbon and forcing a refresh?
Thats maybe the key we need to do here.

I suggest making a variable in code that references the ribbon object, each time a form or report gets the focus the ribbon is invalidated.
Let me know if you need further help in what I just explained.
I think Albert Kallal has a class method for handling ribbons like this I always thought was interesting. I never got into it as I wasn't proficient in ribbons back when I first used it, then had to focus on working in Excel for a while (due to some company focus and policy), which only allows one ribbon at a time but now I'm back to focus on Access but haven't really had to do ribbon stuff. Otherwise I'd probably have a good Access focused example to share personally.
Go to the top of the page
 
ptaussie
post Jul 22 2018, 04:38 PM
Post#9



Posts: 5
Joined: 10-July 18



Thank you JonSmith, yes please, I would be interested in some guidance on what you mentioned, also especially if you have ideas on how to invalidate the ribbon via code and force refresh...
Go to the top of the page
 
JonSmith
post Jul 27 2018, 02:42 AM
Post#10



Posts: 3,958
Joined: 19-October 10



Sorry for the slow reply.

So avoiding classes for now, here is a simple example of a module that will store the Ribbon object as a module level variable which can be 'invalidated' in code, this is the same as a 'refresh'.

CODE
Option Compare Database
Option Explicit
'

'******* REFERENCES REQUIRED*********
'*Microsoft Office 15.0 Object Library
'************************************

Private rib As IRibbonUI 'The ribbon object.


Public Sub ribbonLoaded(ByRef Ribbon As Object)
   Set rib = Ribbon ''We capture the ribbon variable for later use, specifically to invalidate it
End Sub

Public Function MyXL(control As IRibbonControl)
   'Whatever your code normally does goes here
  
  
  
  
   'This forces a ribbon refresh
   rib.Invalidate
End Function



You must also update your XML so the Ribbon object has an onLoad callback. Since you have two ribbons they will conflict if they both us this code as only one ribbon can be stored in the Ribbon variable at once so you can either put a second variable and maybe a tag property to help distinguish which ribbon it is and store them as two separate variables, use two differently named callbacks or work on using a collection and a class.
CODE
<customUI onLoad="ribbonLoaded" xmlns="http://schemas.microsoft.com/office/2009/07/customui">

This post has been edited by JonSmith: Jul 27 2018, 02:45 AM
Go to the top of the page
 
ptaussie
post Aug 9 2018, 06:27 AM
Post#11



Posts: 5
Joined: 10-July 18



JonSmith, thankyou very much for your help. it seems like hopefully at long last i can put this behind me.
i ended up just turning it all back into one standard ribbon, that has all the buttons and manages all it's automatic context sensitive enabling/disabled itself. That way i didnt have to worry about multiple onLoad callbacks. i just called the invalidate function every time the user opens a commonly used form, so it would be happening regularly enough.
Thanks again.
Go to the top of the page
 


Custom Search


RSSSearch   Top   Lo-Fi    21st November 2018 - 07:36 AM