Question on Albert's video regarding A2010
Salad
http://www.youtube.com/watch?v=AU4mH0jPntI, he placed the temp of the
area on the page. How is that done? He mentioned a web control. Do
you drag a web control to the form and it would be similar to a
hyperlink in a table that stores the link to the external site?
Albert D. Kallal
news:ofidnTfSPdu8DZTW...@earthlink.com...
Yes, it just like a text box, or picture control. You drag this onto the
form.
In the past, you could try to risk placing a non native control (activeX)
control of a web browser. however, just about any browser update, changing
to a machine with a user who like Firefox, your application was very likely
to break.
For access 2010, this is just another control in the tool box.
It gets even better:
The really great feature of this web control is that you the data source
(URL) to a column in your database. In other words, the URL of the control
can be a column. So, for displaying manufacture part number, or even things
like pictures from some web page, you just put in the web url. Since it
bound to a column in your table, then when your navigate to a different
record,
then that web control will refresh for you. No code needed...
Not only that, you can use expressions in the data source column. (just
like you can use expressions for the data source of a text box). So,
like any other text box or control on a form, you can use expressions.
Note that a web parameter parser is built in. Here is a screen shot:
In the above, I just hit the expression builder. So, yes, it very much just
like inserting a hyperlink.
In this shot, you see the URL builder:
VERY cool control, and note that parameters can be expressions/functions..
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOO...@msn.com
Salad
That sounds really neat. Thanks for the explanation.
I haven't dl'd Office yet so I may ask a question that is very obvious
after doing so. Does one use something like this web service for a
continuous form as well? Like how you presented pics of the rooms?
Another question. Lets say we had a continuous form that displayed pics
of the rooms. Can one display the pics as thumbnails and by, let's say,
dbl-clicking on the pic it present a larger, full-sized pic of the room?
Albert D. Kallal
>>
> That sounds really neat. Thanks for the explanation.
>
> I haven't dl'd Office yet so I may ask a question that is very obvious
> after doing so. Does one use something like this web service for a
> continuous form as well? Like how you presented pics of the rooms?
The browser control works for both web based, or your longtime VBA client
(desktop) only applications. So, it a new control, and it not restricted to
web only, it works well for client apps also.
In fact, for client (VBA) applications, I think this control is one of the
most useful new controls we received in access in a VERY long time. It has
near unlimited uses...
Would I use this browser control the continues form to display the rooms?
No, I just used the new picture control we have in access. In fact, that new
control arrived in access 2007. And, I actually placed the pictures in the
database (used the new attachment column we have).
So, those pictures are stored in database. I did this for several reasons,
but one reason was then publishing was simple one click to the web, and no
additional work or setup was requited to make that continues form work in a
web browser.
The new picture control in access 2007 is quite nice, as it can be bound to
a database column. That database column can be a text path name to a picture
on your hard drive. Prior to 2007, you could make a picture control display
a picture from a path name, but it requited code in the on-current event to
setup the image control. And, prior to 2007, you could NOT display pictures
in a continues form at all. And, prior to 2007, placing pictures in the
database was a source of huge bloat.
So, with 2007 and 2010, this new picture control does NOT bloat the
database, does not requite code to refresh, and also works in continues
forms, and for 2010, the picture control works in browser based applications
(but, don't confuse browser based applications with the new browser control,
they are NOT related in any way. So, the new browser control is not part of
the new web stuff, and you are free to use this control in your longtime VBA
desktop applications).
However, the new picture control in access is really nice. Things like a
picture of country flag appearing beside a persons name does not take code
to do this. Or you can have a part picture appear beside a part number, or
perhaps a cute graphic folder icon to show the status of a project as being
open, or closed via a nice graphic. So, that 2007 picture control is
nice..and it carries over to 2010. it really opens up the ability to use
pictures in our applications with great ease.
>Does one use something like this web service for a continuous form as well?
No, I did not need nor would use the web browser control to build that form.
That form is just a regular continues form. I make the buttons a bit larger
so it looks more "web like". And, I just drop the picture control onto the
continues form along with those buttons and text boxes. They all repeat over
and over just like all continues forms do...
However, you do bring up an interesting question:
Since the web browser control is bound, one of the first things I tried was
to drop a browser control onto a continues form!
That does not work. At lest in the early beta it did not work (the browser
control was grayed out in the tool box). So, I did try this!! I have to try
this again, or perhaps drop the control into the detail section on a form,
and then flip the form into continues mode to see what happens. Last time I
looked, this is not possible. So the bound picture control does work on
continues forms, but the bound browser control does not work in continues
forms. This is probably a good idea, since repeating a whole browser control
over and over in a form would be quite heavy from a memory and resource
point of view...
I could check in the latest beta preview we all have if this has hanged, but
I doubt it..
So, that continues form in that video was built like any other continues
form in access. I did not have to modify it in any special way when I
published it to the web...
>
> Another question. Lets say we had a continuous form that displayed pics
> of the rooms. Can one display the pics as thumbnails and by, let's say,
> dbl-clicking on the pic it present a larger, full-sized pic of the room?
Well, if you look at that video, that's really how it worked. Those smaller
room pictures in the continues form really were much like thumbnails. Notice
how much smaller the room pics are in the continues form. To accomplish
this, I just sized the picture control smaller in the continues form. I did
not use two sets of pictures. I could have made the room pictures even
smaller in the continues form, but I had lots of room. I suppose if I sized
the picture even smaller in that continues form, it would have looked even
more thumbnail like.
Note that if you click on the picture, the attachment manager comes up
(that's how I view the front/back/side of the room). I did not have to write
that code, it built into the attachment control in access now. I just added
3 pictures to that one records attached field.
Note that clicking on the picture in the continues will also launch the
attachment manger. I actually I actually disabled the picture control in the
continuous form for this reason. I suppose I could put a invisible control
on top, and if you click on the picture then I could simply launch a form
the same way that the edit button (that is right beside that picture).
So, right now just clicking on the edit button does launch the room form,
and you do see a much larger image of the room. I suppose I could make
clicking on the picture do the same thing...
Albert D. Kallal
news:QgkOm.47381
> suppose I could put a invisible control on top, and if you click on the
> picture then I could simply launch a form the same way that the edit
> button (that is right beside that picture).
>
Actually, I just looked, and the attachment control DOES HAVE a click event,
so, I don't even need to use some "invisible" button trick...you can code
this direct on the attachments click event....
Salad
> "Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in message
> news:QgkOm.47381
>
>
>>suppose I could put a invisible control on top, and if you click on the
>>picture then I could simply launch a form the same way that the edit
>>button (that is right beside that picture).
>>
>
>
> Actually, I just looked, and the attachment control DOES HAVE a click event,
> so, I don't even need to use some "invisible" button trick...you can code
> this direct on the attachments click event....
>
>
Picking your brain, Albert.
Wanting some more info. In Access I might have
Docmd.OpenReport "Parts"
and this will display all the parts in the table. I might then have
Docmd.OpenReport "Parts",,,"PartType = 'Engine'"
and all the parts of type "Engine". Can one have filters like that as
well? IOW, create dynamic reports?
When you create a new database now there are 2 options; blank database
and blank web database. What's the difference? Are there more/less
options between the two? Why would one select one over the other?
In a continuous form I might present all employees like a log file. I
might have in the header some filter options; Active/Inactive, a combo
with managers, and maybe Salary/Hourly. Maybe a button to refresh/reset
the defaults to show all. In the afterupdate even of these options I
call a sub to set the filter to display the matching filtered records.
And I might have a dbl-click event to display a single detail employee
record. Is such caabilities available in a web app?
Salad
> "Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in message
> news:QgkOm.47381
>
>
>>suppose I could put a invisible control on top, and if you click on the
>>picture then I could simply launch a form the same way that the edit
>>button (that is right beside that picture).
>>
>
>
> Actually, I just looked, and the attachment control DOES HAVE a click event,
> so, I don't even need to use some "invisible" button trick...you can code
> this direct on the attachments click event....
>
Thanks Albert for all your input so far.
A couple of more questions. Will an Access app on the web be secure for
taking payment transactions? If so, any ideas on how that would work?
If a person already has a web site, can they link to an Access app from
their current web site? IOW, can they click on a link from a page that
fires up the app where needed?
How would/does a web site maintain security? For example, let's say you
have a site that permits various remote offices to enter company data.
But you also want to present public data. Would one have 2 web sites;
one public and one private? Or can one maintain security between the two?
Do you anticipate people developing libraries? Maybe The StoreFront
with an app for selling products, The PartsStore for presenting a list
of parts, The TravelStore for travel, and etc and then people just buy
the library they want?
Albert D. Kallal
>
> Wanting some more info. In Access I might have
> Docmd.OpenReport "Parts"
> and this will display all the parts in the table. I might then have
> Docmd.OpenReport "Parts",,,"PartType = 'Engine'"
> and all the parts of type "Engine". Can one have filters like that as
> well? IOW, create dynamic reports?
Yes, you simply use the openform action. It really the same as what we
always had.
> When you create a new database now there are 2 options; blank database and
> blank web database. What's the difference?
Well, taking a guess? ;-)
Yes, choose blank web if you want to create a web database.
> Are there more/less options between the two? Why would one select one
> over the other?
Well, if you want to create web forms, then you have to create a web
database. The BEST way to find out what features you have (and
don't have) is to create a web database. You can then create some
tables and a few forms. If you create a web form, then you
automatic be limited to web only features.
> In the afterupdate even of these options I call a sub to set the filter
> to display the matching filtered records. And I might have a dbl-click
> event to display a single detail employee record. Is such caabilities
> available in a web app?
Yes, just try creating a web form. You can well note that you can place
buttons
on the form, and when you choose the click event, you see the macro editor,
and
can write code. So, in this case you could use the setfilter command.
David W. Fenton
> "Salad" <o...@vinegar.com> wrote in message
>
>> Wanting some more info. In Access I might have
>> Docmd.OpenReport "Parts"
>> and this will display all the parts in the table. I might then
>> have Docmd.OpenReport "Parts",,,"PartType = 'Engine'"
>> and all the parts of type "Engine". Can one have filters like
>> that as well? IOW, create dynamic reports?
>
> Yes, you simply use the openform action. It really the same as
> what we always had.
Note the terms of art, "openform action" -- that is, you use an
embedded macro, as web forms can't use VBA.
>> When you create a new database now there are 2 options; blank
>> database and blank web database. What's the difference?
>
> Well, taking a guess? ;-)
>
> Yes, choose blank web if you want to create a web database.
I think the question is:
What do you get with a web database?
What do you lose?
It seems to me that you gain the ability to publish to Sharepoint so
that Access Services can make your app available in any web browser.
What you lose is VBA, anything not supported in embedded macros and
perhaps some of the events (I am guessing about that). But the UI is
different for web objects, so you immediately know what's supported
and what's not.
Yes?
[]
>> In the afterupdate even of these options I call a sub to set the
>> filter to display the matching filtered records. And I might have
>> a dbl-click event to display a single detail employee record. Is
>> such caabilities available in a web app?
>
> Yes, just try creating a web form. You can well note that you can
> place buttons
> on the form, and when you choose the click event, you see the
> macro editor, and
> can write code. So, in this case you could use the setfilter
> command.
It's not really code in the sense that we are accustomed to using
the term, i.e., to mean VBA code. It's a structured "code" editor,
but the result is not VBA. And its functionality is not unlimited,
as VBA is unlimited.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Albert D. Kallal
> I think the question is:
>
> What do you get with a web database?
>
> What do you lose?
>
Actually, the question is quite legitimate. The problem is new users are now
staring to play with 2010. They can choose blank database, or blank web
database.
After they done the above, they are free to create standard VBA forms, so,
the users often ask, what is different? I can't see any difference! I still
creating regular VBA forms, so why the two choices?
> It seems to me that you gain the ability to publish to Sharepoint so
> that Access Services can make your app available in any web browser.
>
> What you lose is VBA
yes - for web forms you create...
So, you can't use VBA for web forms, but you can choose to create and build
VBA forms WHEN you choose "create web database". That "mix" I talked about
is legal here.
> anything not supported in embedded macros and
> perhaps some of the events (I am guessing about that). But the UI is
> different for web objects, so you immediately know what's supported
> and what's not.
>
> Yes?
Correct.
Remember, even the macro language now has looping and subroutine calls. Many
of the macro features also become restricted when you choose a web forms.
(especially the VBA function set. Most of the VBA function set is available
in macros..but, when you choose web forms, the features become paired down,
in fact so much so, you have to use web queries and other approaches to "get
back" those features).
So, in summary:
create web database:
still allows client forms to be created
(they will not run in a browser).
These client forms can be either VBA, or macro and they have the full
function set + event sets.
Web forms must be macro only, and the event + macro feature set is
restricted to reflect this.
Salad
If you had a mix/match of forms or reports...since I haven't gotten as
far as publishing an app...how does one know which forms can/can't be
published...is there a list and one selects which ones to publish? Does
the developer name forms like
vProjects
wMain
do differentiate the two. Or is there a listbox that shows the forms
and the type...regular or web?
David W. Fenton
> So, in summary:
>
> create web database:
> still allows client forms to be created
> (they will not run in a browser).
>
> These client forms can be either VBA, or macro and they have the
> full function set + event sets.
>
> Web forms must be macro only, and the event + macro feature set is
> restricted to reflect this.
Can you publish a mixed database to Sharepoint, such that the web
parts will be available to web users and the client objects only to
client users? If so, that's a perfect architecture for the kind of
mixed Access/Web app that Tony Toews often describes, i.e., you want
to give a subset of access to, say, clients, and keep your main app
internal. In the old scenario, you'd build a web app with the subset
of features for your customers (ASP, Cold Fusion, PHP, whatever) and
keep your existing Access app for you employees' use.
What it sounds like to me is that you can now do this in a single
Access app. And anything that's shared functionality between the two
application versions (the customer version vs. the employee version)
could be web forms.
Assuming I've described things correctly, can you have web objects
that *don't* get included when you publish to Sharepoint? Or is it
all or nothing (i.e., all web objects get published or none)?
Albert D. Kallal
>
> If you had a mix/match of forms or reports...since I haven't gotten as far
> as publishing an app...how does one know which forms can/can't be
> published...is there a list and one selects which ones to publish? Does
> the developer name forms like
> vProjects
> wMain
> do differentiate the two. Or is there a listbox that shows the forms and
> the type...regular or web?
They are all mixed together. You will find it very easy to distinguish
between the two types of objects (web form, client form, web report, client
report, web query, client query etc..).
If you are viewing a list of forms, you see that web objects have a global
(web icon) on them...
Here is a screen shot:
http://www.kallal.ca/web1a/accessform.gif
And, here is a screen shot of a VBA form in the web app:
http://www.kallal.ca/web1a/ViewCode.png
In the above, I switch the nav pane from list to "icons" to increase the
size of the objects in the nav pane, but, even in the smaller views...you
will see a global icon inserted on top of the standard access object (form,
reports etc...)
Here is a screen shot with the nav pane in "list" with smaller icons..but,
again you see the objects in the following are all web (note how I used the
"find" option in the nav pane to filter only "boo"...I use the ctrl-f, and
type in boo or whatever to filter objects to JUST see the things I want to
work on...
Albert D. Kallal
> Can you publish a mixed database to Sharepoint, such that the web
> parts will be available to web users and the client objects only to
> client users?
For the web side, it easy since launching it from a web browser, they only
going to see the web based objects.
However, on the client side, it's a little bit more interesting. Your code
(VBA or macros) is free to launch client only forms or web forms. In fact,
you can simply launch by a double click on any object in the NAV pain
including those web based forms. When you launch a web based form inside of
the access client, then the access client launches that web form just like
any other client form that is local. So, web forms can be launched/used both
web side and client side in your applications. Remember, they all be using
data from the SharePoint site...
Of course in the startup options, now have two options:
web startup form
client startup form
So, if you hide the ribbon and specify a VBA client form in the client
startup, your users will not see the nav pane, and thus will not be able to
click on/launch the web forms.
> What it sounds like to me is that you can now do this in a single
> Access app. And anything that's shared functionality between the two
> application versions (the customer version vs. the employee version)
> could be web forms.
Yes, above is correct.
The only real part I miss here is that you can't have ANY local tables in
the client app. So, you can have client forms, client reports, client query
etc. However, you CAN link to an external mdb or external accDB files that
sits on your local pc (or to a network share). So, you can have local data
here, but NO local table in the actual web application is allowed (so, we
don't have client tables, or web tables..they are ALL web tables). Hence,
any local physical table in the "web" app will become a SharePoint table
when you publish for the first time.
However, linked tables to local data is permitted in this web application.
> Assuming I've described things correctly, can you have web objects
> that *don't* get included when you publish to Sharepoint? Or is it
> all or nothing (i.e., all web objects get published or none)?
It is "all" of them go up to SharePoint. So, all webobjects will get
published. No choice.
David W. Fenton
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
>
> The only real part I miss here is that you can't have ANY local
> tables in the client app.
Ack. A major problem. Some tables *belong* in the front end, because
they are intimately tied to front-end functions. That basically
means that any combined app will need to be more complex -- you're
trading one form of complexity for another.
Seems like a silly restriction to me, given that there are obviously
local system tables in your ACCDB, right? So, it's actually an
artificial restriction. Seems like a naming convention could take
care of it, like the old USys prefix from Access 2 that makes user
objects be treated as system objects and hidden from those users who
aren't showing system objects.
[]
>> Assuming I've described things correctly, can you have web
>> objects that *don't* get included when you publish to Sharepoint?
>> Or is it all or nothing (i.e., all web objects get published or
>> none)?
>
> It is "all" of them go up to SharePoint. So, all webobjects will
> get published. No choice.
Hmm. That means careful design, and likely in any scenario I can
think of a web version and a client version of the same form, since
they won't often be exactly the same for your limited-access users.
Of course, that may depend on how much you can alter at runtime in
the web forms.
Albert D. Kallal
> "Albert D. Kallal" <PleaseNOOO...@msn.com> wrote in
> news:UrsPm.796$y%5....@newsfe03.iad:
>
>> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in message
>>
>> The only real part I miss here is that you can't have ANY local
>> tables in the client app.
>
> Ack. A major problem. Some tables *belong* in the front end, because
> they are intimately tied to front-end functions. That basically
> means that any combined app will need to be more complex -- you're
> trading one form of complexity for another.
>
> Seems like a silly restriction to me, given that there are obviously
> local system tables in your ACCDB, right?
100% agreed...I been so busy with so many other issues, I never had time to
bring up and ask why this restriction exists. There some system tables that
remain local. I not tried copy those system tables. I would not be surprised
if we marked the table as system...we can/would have local tables...
> So, it's actually an
> artificial restriction.
It does seem to be. On the other hand, there could be an issue with the
replication of forms + tables since a copy of the accDB file is placed on
the server side. Changes are synced to that accDB file in addition to all of
the web forms being generated. I don't have details or an answer for this
issue right now, but there might some good reasons here..
>
> Hmm. That means careful design, and likely in any scenario I can
> think of a web version and a client version of the same form, since
> they won't often be exactly the same for your limited-access users.
> Of course, that may depend on how much you can alter at runtime in
> the web forms.
Yes, agreed. However, since the application is what launches the forms, and
there is a "isClient" flag available here, then some control is possible. We
are able to specify the web startup form, and the client startup, so from
the get go via the 1st form launched at start very much give a different
starting point for client and web systems (but, you CAN specify the same
startup form for web and client side).
David W. Fenton
> there is a "isClient" flag available here, then some control is
> possible. We are able to specify the web startup form, and the
> client startup, so from the get go via the 1st form launched at
> start very much give a different starting point for client and web
> systems (but, you CAN specify the same startup form for web and
> client side).
But building two independent objects that perform the same task in
the two different contexts is bad design. It means maintaining two
different objects. The ideal is to have a single object that is
adapted to context. Obviously, that means a web form/report, with
it's limitations in regard to code and events and so forth, but
you'd want one form/report for both contexts, and
show/hide/enable/disable at runtime according to the user (or the
context, i.e., IsClient, might be sufficient).