Jay said:
Albert,
That would help for forms, but not for reports. However, I haven't been
able to enable those either. Can you tell me how?
Actually I just took a look at this and you know what, I don't know how! As
far as I can tell that functionality been disabled. And in fact I'm 100% on
your camp that this functionality **should** be available when viewing
reports. I can try and make some kind of excuse, or perhaps point out that
filtering reports is a brand new feature of a2007, however I think this is a
bit of oversight here. In fact the real answer is is that report view is not
allowed in runtime, but ONLY print preview is. This is just a limitation of
the runtime right now. I'm not quite sure why this design decision was made.
(by the way, I think interactive report filters is a terrific built in
feature, and something that MS access is needed for years - it is new to
access 07).
I will play both sides of the fences say that I do considered iteractive
filters somewhat of an advanced option for my users. I could make the case
that this is something that users of the full version only get. The reason
why I make this point is if you look at the posts here, in the last year or
so here, you not seen anyone asking for this feature in the runtime (I
believe you're the first to ask for this, and point this out here).
(in fact if you look at the top number one requests in this newsgroups these
days, you can almost bet for sure that's what the MS access team is working
on - so it's not gonna be this feature at this point in time )
It's also very possible that since we never had this feature before, we
always gave our users a good solid work around (what this means is that
you're actually up a bit more up to speed on using 07 then a lot of us users
here!).
As a general rule I still think we developers should provide some type of
filter form because it removes effort of the end user to "discover" how to
do that filtering.
here's a bit a screen shots showing those filter forms:
http://www.members.shaw.ca/AlbertKallal/ridesrpt/ridesrpt.html
However, I am going to put the suggestion or shortcoming in the suggestion
box to the developers team, because I do agree with you, and I don't know
why the actual interactive report filter options are missing (by the way,
it's not the fact that they're missing in the menus, it's the fact that in
the runtime you can NOT enable them. It is possible that this is a conscious
decision on the developers team, but I haven't heard either way (so, lets
ask for it!!).
I'll be the first to admit that I did not realize that interactive filtering
was not available, but on the other hand as you can see you're the first
person asking for it here. I agree it should be at least available to us
devleopers like the options are for forms (at runtime, but you'll have to
make the effort to expose that functionality).
Now you're just being condescending.
It wasn't my intention to be condescending here, and I do apologize if
that's the way I came off. I should point out that the filter options are
available in forms if you provide buttions, or a ribbon. (my real point was
it's just a question of exposing that functionality to the end user, not the
fact that as we have to develop it ourselves).
And, if Microsoft had done this, it seems to me it would have been pretty
obvious that their users (us developers) would want a simple way to allow
end-users to sort and filter.
Like I said for the most part, you don't see a lot of posts and questions in
the newsgroups asking for these filter options. And, for the most part as a
developer you'll provide the user with some interface to accomplish this
goal. I guess the question is is how much functionality will you provide to
your application in terms of interactive filtering (and how much
functionality were going to get built into the runtime for us?) - Most of
the options for filtering can be done on a form, and that filter can then be
passed to a report...even in the rutnime).
What options and features they put into the products is all based on the
feedback that they get. For example was only about three versions ago that
we finally got a built in printers collecton that allowed us to change the
printer in code without resorting to some complex API code.
The same thing goes for the file browse dialog, now that's built in, but
most of us still continue to use the api code because we've had that code
sitting around in our library grab bag of tools for years.
I still tend to think it's a different kind of target user when you start
having users interactively filter the report (as opposed to building some
kind of user interface that allows the user to select the report and the
critera they want).
At a certain point the kind of functionality you're looking for means that
that end user should be provided with a full copy of MS access. I know a
number of good developers in this group that simply tell their clients to
always purchase the full version when using ms-access. However, I think this
is also about providing us developers with great tools, and in that light I
think the report filtering should be available in the runtime.
