Well, (scratching head), YES, you are, as always , correct, I tested it and it's fine.
Now the business obstacle of using "continious forms". These datasheets are for medical statistical purposes, they are a sries of 11 querry's. Each querry is additive unto the next, so by the time I am done the , last querry could have 60 columns of data. The reasearch staff dumps the table into excel and filters and sorts to their hearts delight.
Continous form is my "last resort".
I was playing with the other option put forth in the MS document I mentioned.
It seems workable , with one exception, I keep getting an error when I try to kill the form.
If i leave the Declare line IN, the code false apart miserably, If I comment out the Declare Function, the form perfroms correctly and fails, telling me that "Sub or function Not Defined" which of course point to the line of code "intResult = KillForm(intHnd)".
WHAT AM I MISSING HERE, The Declare Function is appropriate syntax ?
and is it ok to have this in the actual form itself , or does it need to reside in a common module ?
TY
*****Below is the offending code *****
Option Explicit
Declare Function KillForm Lib "User" Alias "DestroyWindow" (ByVal intWinHandle As Integer) As Integer
--- In MS_Access_Professionals@yahoogroups.com, "Bill Mosca" <wrmosca@...> wrote:
>
> Terence -
>
> Nice to hear from you again.
>
> Change your form to a continuous form. Problem solved. You can make it look like a datasheet by putting the labels in the form header.
>
> Regards,
> Bill Mosca, Founder - MS_Access_Professionals
> http://www.thatlldoit.com
> Microsoft Office Access MVP
> https://mvp.support.microsoft.com/profile=C4D9F5E7-BB03-4291-B816-64270730881E
> My nothing-to-do-with-Access blog
> http://wrmosca.wordpress.com
>
>
>
> --- In MS_Access_Professionals@yahoogroups.com, "buffalome000" <buffalome000@> wrote:
> >
> > This on has me stumped. Using Access 2007, windows xp, shared rived, linked tables and .accde.
> >
> > I have several forms which display in datsheet view, they are used by medical reaserch staff. We have lots of people using these forms, and they could change the column widths, and move columns around. THAT WAS A BAD THING. I tried to find a way to prevent these column changes from being saved. I want the datasheet to revert to it's original layout when the form is opened.
> >
> > I looked for a ssolution online from MS. Found a solution at http://support.microsoft.com/kb/173517
> >
> > I used the solution and it worked. Solution was to place the datasheet as a Sub Form on another form which was SINGLE FORM View. Resized the sub form so it was not apparent the datasheet was a sub form of Single Form.
> >
> > IT DID correct the problem. BUUT ! The customers can no longer EXPORT the datasheet to excel.
> >
> > I presume the Export function realizes this is NOT a datasheet, becasue it's actually a Single Form with a subForm as a datasheet, hence, will not export.
> >
> > 1. Is my assumption correct ?
> > and is there a solution to the excel Export problem ?
> >
> > OR
> >
> > Is there a better way to PREVENT coulumn changes from being saved thent he solution provided in the MS article ?
> >
> > P.S.
> >
> > Sorry I have been away so long, Work Calls :)
> > Terence
> >
> > Hello to John V, Bill M, A.D., Crystal & and the "gang" !
> >
>
| Reply via web post | Reply to sender | Reply to group | Start a New Topic | Messages in this topic (3) |
Tidak ada komentar:
Posting Komentar