How do you change the tab order of a web compliant Access 2010 form?
Normally to change the tab order on an Access form you would select
Design View/Form Design Tools/Design/Tab Order. However, Design View
is not an option with a web form. Thank you.

On Mar 14, 9:29*pm, JJ <jamie.jans... (AT) gmail (DOT) com> wrote:
Hi, I can't see a way to do this, never done a web form before.

It looks like you design your form so that your controls are in order
from top down, left to right.

I did notice that you can place a macro in the AfterUpdate event using
the GoToControl macro command, so that when an entry is made you can
control which control gets focus next.

HTH.

Malc.

JJ wrote:

Personally, I detest the Layout view. Who cares if I can see the data
or not while designing a form or report? Displaying data should be a
toggle event one can turn on or off. You can't even dbl-click on a
control to open a property sheet. Determing the name or even the type
of a control is a PITA.

Perhaps Albert Kallal can tell you a good method. In the meantime
perhaps this will work for you. You have a Web Access db. Create a
blank db that is non-web. That means it has a design feature. Open it
up. Suck the files needed to modify from the web db into the blank db.
Open in design and modify. Close and save. Open the web db, delete
the old files, and import the new. It's extra work on your part but I
don't see why it won't work.

I think (can't be sure what Albert said earlier) that you can publish
non-web dbs to the web. Prior to publishing it to Sharepoint it checks
if it is compliant and if so will publish it to the web. So that's
option 2; forget the web db for design, use the regular one and only do
design work as if the db is for the web. IOW, no vba. Don't use
functions that can't be used on the web. IOW, I don't think it cares if
it is a Web or Non-Web db when publishing, the question is...can it be
published to the web?

My interest is the use of the NavigationWhereClause property. Why did
MS provide it? There's no code/macro examples on the web via google
that I've found. Right now I consider it an added but useless feature
of Access.

?"Salad" wrote in message
news:PZWdnU_mpIr4cx7QnZ2dnUVZ_gidnZ2d (AT) earthlink (DOT) com...

The web form flows from top to bottom (and left to right if controls on same
level).
You can use the goto control command in the after update event to modify
what control will be next for those cases where you want to change this.

That control layout system was introduced in access 2007, and I will say in
my about 14 years of using access, that new layout system in the report
writer is probably the best increase in productivity that has occurred to
the report writer or in fact any part of the layout process in access. That
system means if you resize a column, then the Headings, the footings, and
detail sections all automatically resize and move for you all at the same
time. If you've ever had to simple resize one single control in the middle
of a complex detail section in a report, you then have to go up and move +
resize the heading controls. You then have to go down and resize + move the
footing controls. You THEN have to painstakingly by hand move everything
over on the right part detail section to the left to fill in that gap (and
do it very carefully). It is a just an horrible amount of work. It is
really an understatement to state that something did not need to be done to
address this type of painstakingly shortcoming in access (and competition to
Access has and had been addressing these issues for years).

Not only does the new system allow you to resize columns (with everything
else moving over), you can also delete a column, or even insert a new
column, and once again everything moves over and resize occurs for you
automatically. This layout System Works in both web and client based
applications.

The idea that something did not need to be done to control layout access
when all the competition in just about every other development platform has
vastly improved how the layout of controls works was long overdue. I think
the access report writer been one of the best in the marketplace, but was
very much staring to show its age, and the competition was becoming better
in terms of being able to resize and move controls around.

Now we have a new control layout system and it has raised the bar for Access
in a very significant way, especially when building reports.

Just right click on a control and choose property sheet.

In fact most of the time I use alt + enter key to toggle display of property
sheet. In fact this is what I do in client based applications and forms
also. So, you do not even need to double click.

As noted, just leave the prop sheet displayed, or use alt + enter

The above will work for non web forms, and the non web form will
thus be imported into the web application as a non web (client form).

All client forms pass the web compatibility check since they never
will run in the browser. So, non web forms are allowed in a web
application and they will only run in the client. So importing them
does not get you a web form.

No it cannot. As noted, you can publish VBA and non web forms to the web,
but
you never get to use + view them in a browser.

Because browse to is now the equal of an open form command when you using a
browser based application.

The problem here is if you execute an open form command inside of a browser,
it would launch a whole new browser session and separate form. Then when you
close that form, which form are you going to return back to? How can you
control which of the other five browser sessions you have open? One browser
window open might be Ebay, and the other one might be YouTube and the other
might be Facebook. It becomes impossible to have a bunch a separate browsers
forms/windows launched, and then try to control any type of application
flow. For years as an access developer we always launch one form to the
next and so on. However when using a web based system, then that whole
paradigm breaks down as you now need to control when a separate form is
launched, or when the current browser moves to a different form to display.

In a nutshell browse to is be used when you want to keep the current browser
session and change the form to be displayed. You thus as an general rule
will NOT use open form as that would launch a separate form.

In fact because of this problem where you can't control what forms are open
and what you're going to return back to, the open form command in a browser
is limited to a dialog mode. When you open that form, it actually becomes a
child window of the current browser session (and variables stay intact).
However, if you do launch a new browser, then your varaibles are all gone
(they are separate, just like each front end to a back end, both local and
gobal vars are separate, and so are each browers launched).

So in the case where you want a child window, you will use openform, but it
only going to be dialog. And you do not really want to use dialog forms in
browser based applications, because a whole idea here is is that the browser
window is going to be resized and controls flow down the page. In other
words even the concept of a sized form tends to break down in the web world.

So the open form command launches a new separate form, and that's often not
what you want in a browser.

In effect browseto when used inside of a web browser moves the CURRENT web
browser to the new form to display. This is likely what one wants in most
cases. This also means the back button will return to the previous form. So
browesr two allows you to build an application that behaves like most web
based applications, and that includes the allowing of the back button. (and
you can use a dialog form if you do not want the back button to be active).

In effect thus to change the form displayed, then you will often be using
browse to. And since in web based this much becomes the equivalent of an
open form command, then quite often you also want to supply and use the
where clause. So that's why there's a where clause in the browse to command.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenospam_kallal (AT) msn (DOT) com

Albert D. Kallal wrote:


Maybe it's just the "newness" of the layout format that get's me. I
need to grin and bear it.

Glad you clarified the tab order situation. I was off base. There's no
OnKey events that I see in a webform. I'm not sure how one could check
if a Tab or Shift-Tab was pressed for creating a navigation order on the
form.

The alt+enter method is much faster for opening the property sheet.

I guess I am confused by the web/non-web concept. If a person started
off with a non-web, he'd have to completely rewrite the app for the web?
If so, that could be a lot of extra work. I thought if a form was
written as a web form but didn't use the functionality of a non-web form
it would work in the web app. I'm not sure what a client would say if,
after a month or two of designing an app you say to him...I have to
rewrite the entire app if you want it on the web...even if it was
designed as a web app but on a non-web db.

Regarding the NavigationWhereClause. This is a stupid example. Let's
say the first tab is titled Datasheeet. It displays a list of orders.
The second tab is Orders, third Salesman, fourth Customer. If I am on
Datasheet and I go to the third record, if I click on the Orders it
displays the order of the datasheet's third record. If I press on
Salesman I am viewing the detail record of the Salesman of that order
record and view the detail record of the Customer for that order if the
Customer tab is pressed. I figure that there must be a way to
synchronize the order, customer, and sales records for the record of the
datasheet.

Can this be done? Can the NavigationWhereClause property be used?
There isn't an OnCurrent event to execute a refresh of data. Since
there isn't an OnCurrent event to refresh the data does the update occur
but I suppose they exist in a non-Web form.

I am thinking the BrowseTo command will set the focus to that form. It
doesn't synch the data.

There aren't examples that I can see, on the web, that shows me how to
do that. No code or examples on NavigationWhereClause. That's kinda
where I am stuck.

?"Salad" wrote in message
news:JvSdnd_sl43iVhnQnZ2dnUVZ_oCdnZ2d (AT) earthlink (DOT) com...
Actually your complaints are still legitimate. There are two issues here
with the layout system. The live data preview, and the fact that we have
control layouts to move controls together as a group are actually two
distinct issues. So in the sense that you don't necessarily feel the need
the live data preview, that is fair. Some will like it, and some won't.

I think for form design control layouts are not as useful. So for forms I do
not care a whole lot about live data preview. However, when dealing with an
report, I like both live data and the layout controls are a real honest time
saver. I think for existing applications and most things I have, I do prefer
simple design mode, but some of these new features can really help and terms
of productivity. We will as a community start learning to use and adopt some
of these no features over time. However for web based, we are limited to
those new design surface.

The additional problem and issue of having to use layout mode for web forms
and reports are controls can not overlap like they do on client forms. So
you are forced to use the layout mode. And this means you also forced to
place things in frames or grids. They could've perhaps built something that
took an existing access form and then had some some type of special ActiveX
or client program you install on your browser that renders that form.
However if they'd done so then rendering of those forms would not be pure
web compatible without Silverlight or some type of ActiveX controls. The
decision they made now means that the web applications I'd build work
equally well on my windows 7 phone, but also work equally well on my apple
iPad. So the resulting web forms work in a standard web browser, and there's
no special ActiveX or special downloads that need to occur on the client
side.

Well, actually no, again you not so off base. Being able to set tab order
in our design surface should be a feature that should be included and it's
one that access developers have come to expect and to know for very long
period of time. Having to use code in after update event is not ideal, it's
a work around. The key here's to be very flexible in ones approaches to
designs and what one is going to commit to design wise. In fact the
challenge in web based development is learning what you can't do, and then
modifying your designs to avoid the pitfalls of not being able to do certain
things that you've done over the years.

I think the problem here is always expectations, and the mindset one has
going into these things. I mean when Foxpro developers first came into
access, they could not believe the concept of record numbers must be thrown
out the window. I came from an environment where I could always offer my
customers and clients an undo option in my applications (so if you have
master + child relationship in a form, I can offer the customer an undo
button). Now for more then 10 years in delivering access applications to my
customers, have to say no to a simple undo button feature and I'm unable to
deliver that feature. This is a serious Access limitation, but then it one
we simply learned to work around and we cooked up a new set of tricks and
different approaches that really reduces this limitation to becoming a minor
issue from most my customer.

As a matter of course one has to assume and hope your web base forms are to
be simplified and laid out a good cleaner and less cluttered then client
forms. You have to hope that the layout and tab order of controls that you
get defaulted is going to suffice for the vast majority of your
applications.

We have to keep in mind is is this web version really amounts to web version
1.0 for access. However the web is coming and the future for everybody in
our industry is a movement towards web based applications. Just like those
who resisted the graphical user interface when we went from green screens to
the mouse, we are on a road where we MUST make the transition from the
desktop to the web.

So, we have to set our sights on the web as our future.

In fact when I use control f find + move along the navigation pane on the
left side, after using up down arrow keys, I then go shift control enter to
open the form in question to design mode. I then often whack alt enter to
display the property sheet. I usually then hit alt enter again to hide the
prop sheet when done. I do this since that gets me back to the form, and
ctrl w will then save the form (so, all keyboard, no mouse). This hide +
show prop sheet really saves a lot of focus switching back and forth without
the mouse.

Essentially you are quite correct. On the other hand if you had some complex
payroll system then it not like you can assign the average web user to that
application without many days of training on how to use an application
anyway. On the other hand the bits and parts to gather some employee
information are the only parts you want and should transfer to the web
anyway.

I explain this concept in detail when thing about web vs. connectivity
here:

http://www.kallal.ca/Toweb/Index.html

Yes. In fact how it works is if you designate a form as being web based, it
will work in a web browser, and that is the end of it. If the form is
designated as not being web based, it will not work in the browser. There is
no in between and web forms are automatically restricted to web only
features.

It is unfortunate for this version of access some type of client to web form
conversion utility did not make the cut. On the other hand considering how
spectacular and different web based architecture forms are, and how they
must be laid out far more carefully, the best a conversion utility could do
is get you some basic layout. The coding is also different and I'm not
really sure is worth the effort anyway. I'm pretty much of the thing that if
a form is to be web based, then one should correctly set up the control
anchoring and setup the of controls correctly. Access now (client and web)
supports controls that now resize and grow when you resize a form. This
anchoring ability was added due to the requirements of web based
development, but it's also quite nice for client based applications

I mean last time I looked the safari in web browser running on your Apple
iPad does not have record sets. So you don't have record set processing
inside of a web based form, and in fact the code you are writing in that
access form will eventually run inside of the person's browser as JavaScript
ON their desktop. That code you are writing is web based client side code
that will run inside of the browser, and is not server side. On the other
hand you can also have that form run some server side code if you choose.

I mean either we adopt web standards or we do not. If you looking for remote
use of your access application then you not looking for a web based
application. You been able to use Access applications remote for years by
using windows terminal services.

I do not think people will put themselves in that kind of situation.

As I stated, if you designate a form as web based, then it will work in a
browser. You can have a mix of VBA forms and web based forms. And those
forms in the client side can open each other type of forms. And in fact in
the client both types of forms look and behave like regular access forms.
However when you publish only the web forms will run in a browser.

OK in above I assume you mean a navigation button on the navigation control.

Well I assume in above we click on a row and then use browse to command to
change the active form to our orders detail form. And we're going to want a
use a where clause when we do that switch to displaying the order detail
form. So when you click on that detail button, we want the orders detail
form to display, and will need to filter it (it's really that simple).

Keep in mind if the form you specify in the browse two command does not have
to be part of the current navigation control set. And in the this case then
the existing form is replaced (which is probably what we want in this case).

So access will automatically switch the active control (button in nav
control) to being active and display the form in the nav control. However
keep in mind as stated when you use the BrowseTo Command, the highlighted
NAV control button does not necessarily have to change and will not if the
form we specified to switch to is not part of a navigation control group.

And again, either way, we need a where clause here to restrict the form to
displaying the one record we want.

Yes you quite much have the correct idea. This is exactly what we're doing
here, and we're not setting the property here. We are going to execute a
browse to command in code. This is exactly like when you do an open form
command and we use the "where" clause. If you look at the form, then you see
the filter property of the form been set by the openform command. And again
most time we not using code to set the forms filter property, but we're
using a where clause of the open form command.

So like I said on a conceptual level, we're going to use the BrowseTo
Command in place of the open form command in those web based applications.
We're simply going to open a form, with the filter or what we call a where
clause.

Well, not 100% sure what you mean by sync the data. It simply filters a form
just like we would with a where clause + openform. I think that's what you
mean about by sync the data. So we are to simply filter the form to one
record like we've always done in the past with the open form command.

So, the BrowseTo command really does need a where clause. So as noted it
really as substitute for open form command in web based applications.

Actually most of the sample web based templates have some examples of the
BrowseTo Command.

So just keep in mind, in a hypothetical example above, when you click on one
of the details or one row of the continuous form, our code will run and we
want one of two things to occur:

1) launch a child window in which to edit the one record inside the browser.
This will be a dialog form, and it'll appear inside of a browser window with
the other form behind in the background.
(the above is done using the openform command + where clause)

2) have the WHOLE browser switch to the form?
(the above is done by using the BrowseTo Command + where clause)

So you really have a choice here of using openform, or BrowseTo, and it's
really going to come down to what you actually want to occur. (child window
or have the browser switch to form).

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenospam_kallal (AT) msn (DOT) com