0

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?

Improve this question

2 Answers 2

Reset to default
1

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.

Improve this answer
6
  • Hmm... that's the most worrying part, is I've already set it up that way. GotoControl is called from the form with the TabControl1 ('PartDetails'). The page names and subform names autocomplete as well. No Forms reference included, as you said. I'm starting to think this truly is a bug, or exactly as the error says: "The GoToControl cannot be used to go to a subform or tab page in Web forms." Worrying because BrowseTo works perfectly in web, and can swap out subforms entirely. If I had known I could've built similar functionality to TabControl with BrowseTo and a single subform.
    – IT Bear
    Commented Jan 20, 2015 at 17:39
  • With further testing I was able to reproduce this error in a fresh database. Start with Access 2010 SP2, and create a new blank web db. No tables required, just create a blank web form with a button and a TabControl with Page0 and Page1. For the button's macro, make it GoToControl=Page1. Save the form and try it out, it should work perfectly. Now before uploading to SharePoint, you will have to set the "Web Display Form" to the one we just created. Now do Publish to Access Services and choose a SharePoint 2010 Server with SP2. Open the DB in web browser, and the button's macro no longer works.
    – IT Bear
    Commented Jan 20, 2015 at 17:56
  • Note that the code will work + run in the client side, since controls behind a tab are rendered and exist when the form loads. For a web browser - read my above extended answer - such controls have NOT yet been rendered, and thus goto control will not YET work. Once you displayed that tab, then your code should work since the controls have been rendered and thus are now part of the DOM.
    – Albert D. Kallal
    Commented Jan 21, 2015 at 20:59
  • Albert — I have tried what you said, and even with the tab Page I'm trying to "GoTo" selected & rendered in browser, I still get the error. I've tried to "GoTo" the TabControl first and then the Page, and even tried placing the code within the TabControl itself. Same error every time. I've updated my answer with steps to reproduce this error for yourself, as well as a sample database that demonstrates it. I understand your answer in theory, but in practice it always fails. Cheers if you can get it to work.
    – IT Bear
    Commented Jan 28, 2015 at 20:06
  • You cannot switch the tab via code in web based (and I never suggested you could). So using goto control likely not going to help you much. What I stated is you cannot “reference” the control until it been rendered. However goto and referencing are TWO VERY different issues. So in general you cannot execute the goto control command until such time that tab + control has been displayed. (a VERY big difference).
    – Albert D. Kallal
    Commented Feb 14, 2015 at 18:49
0

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.

Improve this answer
1
  • No, actualy not a bug - see my follow up notes in my answer.
    – Albert D. Kallal
    Commented Jan 21, 2015 at 20:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.