Gustav Brock
gustav at cactus.dk
Wed Apr 21 03:19:20 CDT 2004
Hi Susan
Well, I didn't try to prove an alternative method would be "easier",
and you didn't specify that the report should be able to run without
the form open; it sounded liked you opened the report from a button on
the form after having selected a First-Day-Of-Week.
I agree that for wild "applications" where users can do anything even
having access to tables and report/form design you must take into
account that this or that form may not be open or may have been closed
by the user. There are many ways to handle these chaos scenarios,
ranging from simple error traps and message boxes to, for this case,
forcing the report to open the form if it is closed or closing the
report on open if the form is not open.
The missing selection of a First-Day-Of-Week on the form could be
handled by setting a default value.
For myself, I would probably apply the suggestion of Stuart, but I
realize that static functions may fly above the head of the average
user.
/gustav
> If the expression's in the query and you open the report without specifying
> the value in the form, how would you prevent an error in the form? I suppose
> I could just handle it and remind the user to open the form and choose the
> first day of the week.
> Right now, I've set the report to default to a value and since the
> expression's in the report, it works whether you start from the form or just
> open the report. You can't specify the grouping value when you open the
> report that way, but at least there's no error -- which is a nice
> alternative especially if the first day of the week seldom changes. That way
> the user's not forced to go through the form every time.
> I realize I sound really picky -- but these are the sort of nitpicky
> problems I get from readers. These solutions have to be as universal as
> possible or I get email. :) "It won't work if...." even when I've told them
> clearly in the article that it won't work if... but somehow it's still the
> article's shortcoming. It's always best if I can head them off.
> Which reminds me -- can someone explain the vbUseSystem constant? There's
> almost nothing about it on msdn. It's a system default, but there's not much
> about it. Well, the serious search-challenged was unable to find anything on
> it besides a vague reference -- no real explanation of the consequences.
> Susan H.
> Hi Susan
> In the query you can pick the value from the form as an expression:
> Select
> ...,
> [Forms].[frmSomeForm].[txtTextbox] As FirstDayOfWeek
> From
> ...
> Is is recommendable also to specify this as a parameter to avoid type
> mismatch errors, indeed if the textbox is unbound:
> Parameters [Forms].[frmSomeForm].[txtTextbox] Byte;
> I don't know what your module does, but basically the date of the first day
> of the week of datDate can be found from this formula:
> DateWeekFirst =
> DateAdd("d", vbSunday - WeekDay(datDate, FirstDayOfWeek), datDate)
> You would need to replace vbSunday with the actual value (1 for A97).
> End Function
> /gustav
>> Let me rephrase that -- if I have to have a module, I don't think I
>> really care what gets passed where -- my hope was to eliminate the
>> module and do all the calculating in the query or the report and I
>> thought I might be able to bypass the module using the openargs
>> argument. Replacing the module I have for one that passes the value to
>> a query really doesn't resolve the issue I had.
>> Susan H.
>> That's what I'd like to do -- and may do yet by passing the
>> firstdayofweek value from the form to the query instead of the report.
>> Truth is, I don't know how -- I can't remember ever passing a value to
>> a query before and a parameter query is out.
> --
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com