Albert Kallal's Outlook-Style Calendar

Vincent

unread,

Oct 21, 2010, 11:00:54 AM10/21/10

to

Is anyone familiar with how Albert Kallal created his outlook-style
calendar for the web (http://www.youtube.com/watch?v=AU4mH0jPntI)?

He stated that the calendar is simply composed of 42 text boxes. But,
how is the day number appearing (1,2,3,etc.) if it is not in its own
text box (for a total of 84 text boxes)? Also, if this is simply a
bound form, I'm a bit confused how the binding takes place. Wouldn't
this have to be a continuous form with 7 columns for the data to
appear properly? And that does not answer the question of how he is
positioning the first day of the month in the proper column...

This is obviously an excellent piece of work, but I am having some
difficulties determining exactly how he created this. Can someone
point me in the right direction? I'm sure once I understand the
fundamental idea, I wouldn't have any problems replicating this.

Thanks.

Vincent

paii, Ron

unread,

Oct 21, 2010, 12:20:02 PM10/21/10

to

"Vincent" <animed...@verizon.net> wrote in message
news:37678378-2302-43df...@t20g2000yqa.googlegroups.com...

It is a unbound form. It's controls are show / hidden and filled in the OPEN
event and by clicking controls that change the month.

Albert D. Kallal

unread,

Oct 21, 2010, 2:12:04 PM10/21/10

to

?>"Vincent" wrote in message
news:37678378-2302-43df...@t20g2000yqa.googlegroups.com...

>He stated that the calendar is simply composed of 42 text boxes.

Yes, there is 42 bound text boxes.

>how is the day number appearing (1,2,3,etc.)

Those are text boxes, but they are not bound.

So, to be clear, there is 42 bound text boxes.
The other 42 boxes that display the date are an expression that displays the
correct date based on the start of the month.

I think there are as many ways to approach this problem as there are flavors
of ice cream.

In the following screen shot, I used 42 sub-forms:
http://www.kallal.ca/ridestutorialp/setdriver.htm

(see the 3rd image in above)

The above screen shot of the calendar was built using 42 sub-forms. This is
a more elegant design then the web example code wise since the click event
code was only written once and placed in ONE sub-form. Any change to code or
style to that one sub-form is repeated instant for all 42 sub-forms. (the
click event passes the date value to code in
me.Parent.MyDateChoice(datevalue)). So, I built one day sub-form with code,
and there is only ONE copy of that sub-form, but 42 of them. This is really
a object type of approach in access. Sub-forms a really great in this
regards.

In the above, I use VBA code to load up the date text boxes and also that of
the date values. So that calendar uses un-bound text boxes. The beauty of
42 sub-forms is there little code, and I only had to write the click event
code and place one text box in a little sub-form. There also a few other
interesting features (such as the shaded days boxes that are not part of the
current month) only once for the sub-form.

However, since I was building a web based form, quite a few issues came up.

* Max number of sub-forms (I think it is 10), so sub-forms could not be
used.

* sub-forms take a lot of time to re-plot, but to their credit they run/plot
asynchronous in the web browser, and you can type work before they are all
finished loading.
However, they load too slow for a real nice effect. You can see each one
load separate, so this was not going to work.

* I had to cook up a design that reduces display code since we don't have
VBA for the web form. And, since this was a web form then that web form is
running top of the users desktop inside of a web browser. So, reocrdset code
etc. does not exist in that web form. The code and functionally thus has to
be moved to the server side. So, bound text boxes, and table triggers to
manage and push the text around is how this works. Bound text boxes = much
less code on the UI side.

* I wanted a butter smooth result for the web browser, so I went with a
simple bound design. In the above non web example with 42 sub-form, lots of
code runs to display.
For the web, VERY little code runs to display one month. So, data triggers
(table logic) runs to update things. So, you reduce the code in the UI part
of the application by using bound text boxes, and more code occurs at the
time when you modify a booking (and as noted, that is table time trigger
code).

So, those bound text boxes make month navigation very easy. A simple filter
of year and month, and the whole calendar updates the screen and you are
done. I turned off the record navigation buttons, but even a simple
navigation to the next record would mean that no code need run to update the
whole screen to move to the next month. I as noted I approached things this
way since VERY nice smoothness for the web was an really an important design
goal I had.

So, I tried quite a number of designs, and learned a great number of tricks
along the way to make this work. I had to dump rich text boxes, and that
really hurt me.

So, perhaps I was not 100% clear, there is more then 42 text boxes. However,
the main date text display text boxes are/was what I was referring to. The
boxes that display the day date (in blue) are not bound, but an expression.
However, I could have in fact used one text box with an expression that is
concatenation of the date expression + the text for that date. I still may
consider doing that.

And, a few other text boxes like the date combo box at the top are also
bound.

I written calendars on every platform from Pascal to FoxPro, to Pick/d3, to
Access, to Access web and a few more. They are not that hard to write once
you done a number of them. This is the first design I done however that used
table triggers for a calendar.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenos...@msn.com

Albert D. Kallal

unread,

Oct 21, 2010, 2:24:27 PM10/21/10

to

?"paii, Ron" wrote in message
news:i9pp6h$8o9$1...@news.eternal-september.org...

>It is a unbound form. It's controls are show / hidden and filled in the
>OPEN event and by clicking controls that change the month.

See my other post. I in fact did use a bound form. Navigation to the next
record (which is the next month) means no code at all needs to run to
display and move/change to whole new month.
However, I turned off the record navigation buttons.

So, this is a bound text box design, and while I outline a few of the
considerations in the other post, this is web based form, so you don't have
recordset processing on the web form side, and any recordset processing or
pulling of data has to occur server side.

That code and calendar runs INSIDE of a standard web browser on your
desktop. The code in that form is NOT running server side. This is what
makes access web services so very interesting (it is a true multi-tier web
system). Code you write in a web form in Access runs on the users desktop,
not on the server side. Last time I looked, your iPhone and safari browser
does not have recordset processing, but I run and tested that Calendar using
my iPad, and it works great. So, the forms code in that calendar runs local,
even when I run it using my iPad.