Ms Access Web DB (Access Services) GotoControl functionality broken

Question

I am developing a web database in Access 2010 and uploading it to our Sharepoint 2010 server.

I found a bug in a simple macro command that only exists in SharePoint.

The command is "Gotocontrol" in a macro that is run whenever a form is opened in the web application.

The popup form is "PartDetails" and has a TabControl, clicking on each tab brings you to a different "Page", exactly like in any web browser.

"Gotocontrol" is trying to automatically navigate to a specific page on the TabControl after the form opens, depending on where it's called from. If PartDetails is called from the Value page I have the same PartDetails form open but to the "Cost" tab automatically (to show cost history for that specific part). In the end this will save users extra clicks if they're doing research on lotsa parts, which is likely.

In Access 2010 client this control works perfectly, no fuss. I can upload the changes to the server too, again no problems. Now when I try that same control in the web browser I get "The GoToControl macro action cannot be used to go to a subform control or tab page in Web forms."

That would be fine with me if it simply wasn't capable, but while I was researching this I found: "The issue of GOTO a control was fixed for the retail edition. I remember this as it was a bug that I actually filed. So, yes, goto does for for me. [sic]" — (Albert D. Kallal)

So now I'm told that this actually SHOULD work, but mine isn't. I assume it's something in SharePoint or my implementation of Access Services, since it works fine in the Access 2010 client and doesn't error when uploading to the server (which it normally will do for even the tiniest incompatibility it doesn't like).

So, is Albert Kallal correct, is this issue already fixed and I may just need to update my SharePoint or Access Services service? If so, is there a specific patch released and could I have help finding it & installing it?

Or, is Albert wrong? (maybe he misunderstood the necessity of a WEB database hosted BY SharePoint). In which case, is this a confirmed bug, or a confirmed issue they will not fix? It would be nice to know before moving forward, cause this means I will have to re-create the same forms again in different ways since I can't re-use the existing ones, this creates more work for me.

Edit: Forgot to mention this originally, my Access 2010 SP2 version is 14.0.7104.5000 and Windows Update doesn't say I am missing any updates. Central Administration says Microsoft Access Services Server is 14.0.4763.1000

Edit 2: Yes, I have noticed my Access Services version is the RTM version, meaning there are two service packs I could experiment with first. I'm currently in the process of planning out these upgrades in a reversible fashion. If the upgrades are successful I will re-test and post my results here, standby...

O.K. so SP1 is applied, Central Administration reads all services are now 14.0.6029.1000 and upgrade report says 0 errors and 0 warnings. However, problem still exists. Next is SP2 upgrade, standby...

O.K., now I really do need help. SP2 is applied successfully and problem still exists. Albert Kallal said that this was fixed for retail edition and now I'm at Service Pack #2. I ran SharePoint Configuration Wizard after each update package and Central Administration's 'Upgrade Status' shows two upgrades at 1/15 and 1/19 both successfully applied with 0 errors and 0 warnings. "Access Services Server" under Upgrade and Migration -> 'Check product and patch installation status' shows it has SP2 at Version 14.0.7015.1000.

Now I really don't know what to do next. Please advise? Keep installing more updates?

Answer 1

Confirmed this is a bug and it is reproducible.

I guess maybe we should call it an "error" rather than a bug since they do have a message that specifically outlines what's going on.

To me it is a bug because there are other commands in Access (such as "BrowseTo") that are more powerful and can replicate the same functionality. If I had known (and you know now) before building up my application with a TabControl I could've saved myself a lotta work and trouble.

I have built a sample database reproducing the bug, and giving a workaround that produces the same functionality. TabControlTest.accdb (1.12 MB)

I wrote up a more thorough post explaining the bug in detail, and giving steps to reproduce it as I have. It can be found here. The first half explains my situation already covered in the question, so scroll the the bottom half for screenshots and reproduction steps.

Answer 2

Goto control was fixed, but you cannot move a control in another web form. So you cannot modify or change the controls say in another web form that might be doing your on-line banking.

So goto control should work just fine, but the code has to be executed by code INSIDE the form in question. So if this form in question is a sub form, then the code has to be running inside of the sub form, and not from another form that as noted might be doing your on-line banking etc.

As if memory serves me correct, because of this, then you don’t and cannot include the forms reference – you just use the control name since it has to be from the current form.

And you also see this effect with tabs, but for a different reason.

Controls on tabs are “dynamic” loaded. That means the controls don’t exist nor are rendered in the browser until such time that you display the text boxes. In fact this is MUCH the same in .net – text boxes NOT YET rendered in the browser cannot be referenced.

Access is the same. If you jump to the tab in question (manually) and then go back, and then run your goto control code it should now work. However until such time the control in question has been displayed and rendered by the browser then you cannot set focus to such controls – as noted, this is the case for most web browsers. Some browsers might behave different, but for the most part they all work as per above.

You MUST remember that code you are writing in that web form is NOT running server side, but is running on the users desktop. The ‘DOM’ (document object model) of that web page thus will not contain controls that have not yet been rendered and thus you cannot "goto " them. Note that for controls set visible = false they can be referenced, but such controls would have the SAME limitations as per above. Thus even invisible controls cannot be referenced until the web page or part of the web page containing that control has been displayed and rendered.

Once such controls have been rendered (and now become part of the DOM), then both visible and in-visible controls on that part of the web page can be referenced.

So this effect is due to the dynamic loading abilities of a web browser and this design is not only by intention, but is an industry standard effect you will see in all of the mainstream browsers ranging from Firefox to IE to Safari.