I don't have A2010 yet.

In a desktop application you can store pictures in a table. Or one
could create a hyperlink to the image. Since Web apps contain a lot of
images and pics, how does one handle pictures? How does a user of tha
app upload a pic (is there a fileopen dialog)? Would one have a web
site that perhaps stores pics in a folder and store the hyperlink to the
picture of that folder in the table?

If it's possible to upload a pic and not need to store the pic in a
field in the table, what method does one use to copy the image to a folder?

Salad <salad (AT) oilandvinegar (DOT) com> wrote in
news:LeudnX3mi6HPU9jRnZ2dnUVZ_tednZ2d (AT) earthlink (DOT) com:

Again, I am not using A2010 yet, either, but I think you're raising
a really important issue that the promotion of the new features of
A2010 for the web have glossed over. That difference is that this
new method of publishing an Access app to the web is not really the
same thing as creating a website at all. Websites have a lot of
stuff wrapped around the database interaction forms, such as site
navigation, ads, etc. None of that can be done from within Access.

Albert, and others -- are there provisions for embedding the Access
app inside a web page that has things in it that aren't part of the
Access app? I would expect not, but MS has really surprised me with
how much they've done in this release, so I'm all ears.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

David W. Fenton wrote:

Do you point a hyperlink at a website to the app site?

Although getting away from my original question on pics, what does one
do to drive people to the app? Does on need to get involved with google
analytics?

"Salad" <salad (AT) oilandvinegar (DOT) com> wrote

A good question.

There is a few choices, and I try to answer all your questions.

The simple approach for most forms is to simply insert a image into the
form.
(don't worry, this gets better!)

One nice addition to access 2010, that works both in client based
applications and web based applications, is a new option for imbedding
pictures into a form. In the past when you dropped an image onto a form, we
had linked option and we had the imbedded option. You will now see a NEW
third option called "shared".

If you choose the shared option in the property sheet for an image control
(when working on a form in design mode(, then the option for where you in
the past typed in (or browsed) for the picture becomes a drop down combo
box. That combo drop down will then show all of the CURRENT pictures you
have in the application (all the imbedded pictures).

So, you drop the image control into a form, select "shared", and then select
from the drop down any picture currently imbedded in the application.
Because this is 3 steps, there is also new "one step" to this by using the
image gallery that now appears in the ribbon. This ribbon option is a one
mouse click affair, but is in effect the same as the above outlined 3 steps
(I did not realize for some time this was the case).

Here is a screen shot:

http://cid-b18a57cb5f6af0fa.office.l...ing/imageG.png

I love this new gallery, and it even works for older applications. All it
really is doing is to simply let you view/see all of the images in the
application. And, of course access fixed (finally) the bloating problem with
embedded images. And even better is now that you can share those images, and
then this keeps the file size down even smaller. And, support is built in
for transparency in images.

Keep in mind one more interesting and significant aspect about the new image
gallery system, is that you can go in there and replace an existing image
with a different image. In the case of a client only application, thus if
every form, every report etc. has a corporate logo, and you needed to change
it, since there is only one instance of that image, then you can use the
image gallery on the ribbon, and replace the ONE image. Since there is only
one instance of the image, then whole application is completely changed by
that act. So, every form/report that was based on this image will reflect
this change.

I should point out the same effect also occurs and works well in web based
applications. So, once again if you use the image gallery management system
and replace that one image, then you publish, then every place in the web
site is now instantly updated.

This simple image change thus dramatically improved image handling and the
ability to place images inside of your Access applications. (both web and
client)

So the above issue is one suggestion and you thus drop the image on your
form and publish to the web.

The next question what about the case where you want to upload images, or
you don't want the image to be part of the application itself?

Let's say you wanted to have a family album with person's name and you want
the users to type in their name and then upload an image of themselves. In
this case you can use the new attachment field and bind an image control to
that. This little simple trick works absolute wonders, because not only does
it allow you to upload images to the website, but even more incredible is
behind the scenes somehow SharePoint actually generates a full path URL you
can use and link to. In other words if I upload an attachment field as a
word document or in this case a picture, then you get a URL within your
website that you could actually e-mail to somebody.

Regardless if you need the URL or not, the attachment feature lets you
upload images and attachments into a database, and it does so inside when
using a web browser (it launches the file browse dialog). In fact in my room
booking application, this continuous form show some images, and while the
new image control does allow to be used in continuous forms, I in fact used
the attachment field for this example application, because the idea was to
allow the manager of the application to setup the room pictures. Here is a
screen shot of the continues web form:

http://cid-b18a57cb5f6af0fa.office.l.../roombook1.png

(note, after you click on above link.click on the link again to zoom in
better)

Here is one of those forms opened up:
http://cid-b18a57cb5f6af0fa.office.l...ng/webctrl.png
(again, after you view above..click again for better view)

So this handles the case where you need users to upload pictures and
photographs perhaps even for parts catalog or whatever. And like I said, I
don't know the details behind the scenes, but while you can view those
pitchers inside of an access form as above, there's also that great addition
of an absolute URL being generated for each uploaded attachment.

Last but not least, there might be a case where you have a large existing
web site of lots and lots of pictures. In this case I would just simply drop
in the new web control onto the form bind it to a column in the database
that has the URL that points to this image on the other web site. While I
think the new web control has more uses in client only applications such as
showing flash or cool things like java in a form, the web applications also
can use this control also.

So, you simply drop in the new web control into your form, and bind the web
control to a column in your database that points to the picture on that
other web site.

In a nutshell, you don't have a resource library in the traditional sense of
a web site, but the above scenarios I Point out above tends to be quite
flexible, and for the most part right now I found to be more than adequate.

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

Albert D. Kallal wrote:

Thanks Albert for answering the question. A lot of the social
networking sites (sns) permit the uploading of files and the concept of
an attachment field makes sense. Although I wouldn't expect an Access
app to be a sns, the ability of someone to upload a pic would/should be
expected.

Salad <salad (AT) oilandvinegar (DOT) com> wrote in
news:K46dna2q5eMuRNjRnZ2dnUVZ_g-dnZ2d (AT) earthlink (DOT) com:

I don't really see using Sharepoint as a public web site, though I
guess it's theoretically possible. I am unclear on the authorization
model used by Sharepoint, though. I would have expected it to work
better on an Intranet than open to the Internet.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

David W. Fenton wrote:

internet. I guess he can answer better than I.

Yes, I can see it used internally but I don't see a reason it can be
used publicly.

"Salad" <salad (AT) oilandvinegar (DOT) com> wrote


I've only just got a couple minutes and I have to run (very busy right now).
There is a bunch of threads and questions here, and I've been meaning to
answer am, but it just don't have the time right now in the next couple of
days to get back to here. And, time spent here means I not dealing with the
ton of isses I need to SharePoint wise.

For that room booking example, that's generally going to be nonpublic
(internal) So, organizations and corporations that have several rooms for
booking will use this web site internal and don't allow the public to book
those rooms.

However I do have plans to add some more event features to that room booking
example. So, you might have a three day technology conference where there's
10 different rooms with each several presentations during the day. In this
case it would most certainly makes sense to have a public facing web site to
allow people to sign up for the seminars and book into those rooms. (and, I
am even looking for payment processing solution for this). Of course this
would allow the organizers know when a room is booked full, or they could
even consider moving it into a larger venue. Printing of each users schedule
and what events etc would be a great use. And the built in email
notification systems in SharePoint are a dead winner for this type of
application.

So, right now the concept and idea behind that room booking application is
for internal organizations and companies that have several board rooms or
simply conference types of rooms to book. However, I can certainly see some
scenarios where I'd like to extend it to a public facing system and I have
plans to do that quite soon in fact, I'm just sorting out the authentication
and logon process for this as we speak now.

In fact I probably would've thrown up a couple links for folks here to try
some my sharepoint stuff in public, but I I'm simply too busy right now to
set this up in a proper fashion for demos, but I will get around to doing
this when some time frees up, but I have too many piles.

However you should keep in mind that there is a growing number of public
facing SharePoint sites.

Ferrari
www.ferrari.com

CASE tractors
http://www1.caseih.com

Viacom
http://www.viacom.com

Here a cool list:
http://www.wssdemo.com/Pages/topwebsites.aspx


So, SharePoint does have the ability to deal with NON Active directory
users. So, most stuff is based on active directory, but Sharepoint also
supports a second method of logon called "forms based authentication". In
effect what it means, is you can build public facing sites, and even design
and build users with a self signup process. You can of course allow
anonymous use of the sharepoint site also. This is a pretty big topic to go
into right now, but suffice to say there is two methods of authentication.
You don't and will not write this user stuff in Access web. Both of these
methods of authentication are pretty much transparent to the rest of the
sharepoint site in terms of how say Access web services will "see" and deal
with the user (and what email is used for when you use the "send mail"
feature of SharePoint for example). And when access web code does things
like GetCurrentWebUser(1), it will work the same for both sets of users. (AD
and FBA).

If you think about the above, it's not common, but I would say extremely
common to have a web site in which you have users sign up and therefore then
be forced to log on or sign in to manage their security. Suffice to say that
sharepoint has support for this. You will however have to setup a self sign
up process with features like passwrod re-set, or even support of those
"captia" (those hard to read grapic things so often seen during signup that
I hate).

I simply have to run, I stop here.....

"Albert D. Kallal" <PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote in
news:Ks12o.14072$hF1.7738 (AT) newsfe14 (DOT) iad:

So, basically, it sounds like your Access web app would be unchanged
by this, and Sharepoint provides the web wrapper around it for
non-AD user authentication/account setup, etc. But once logged in,
GetCurrentWebUser(1) provides you to check who that non-AD user is.

That seems to cover it!

I'm pretty impressed at how thorough MS has been with implementing
Access Services on Sharepoint. So far, I don't believe I've noticed
anything they've failed to account for.

I may have to entirely change my thinking about how appropriate
Access is on websites.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/