Thanx John,
I think what happens is when I leave the Declare in the From instead of a "Standard Module", The translate/compile just gets screwed up. The message displayed basically indicates that the compile cannot resolve my BlahBlah_onClick events. They are there, and are correct, I think my leaving the "Declare" statment in the form is simply reeking havoc.
I did move the declare statment to the Standard Module, and the compile works fine, and the technique now appears to work.
Thank you John.
--- In MS_Access_Professionals@yahoogroups.com, John Viescas wrote:
>
> Terence-
>
> Put the Declare in a Standard module, not the form module. When you include
> the declare, how is it that the code "false" (falls) apart?
>
> John Viescas, Author
> Microsoft Access 2010 Inside Out
> Microsoft Access 2007 Inside Out
> Microsoft Access 2003 Inside Out
> Building Microsoft Access Applications
> SQL Queries for Mere Mortals
> http://www.viescas.com/
> (Paris, France)
>
>
>
> -----Original Message-----
> From: MS_Access_Professionals@yahoogroups.com
> [mailto:MS_Access_Professionals@yahoogroups.com] On Behalf Of buffalome000
> Sent: Thursday, January 03, 2013 1:51 AM
> To: MS_Access_Professionals@yahoogroups.com
> Subject: [MS_AccessPros] Re: started with preventing layout changes to
> datasheet - now cant export to excel
>
> 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"
> 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-6427
> > 0730881E
> > My nothing-to-do-with-Access blog
> > http://wrmosca.wordpress.com
> >
> >
> >
> > --- In MS_Access_Professionals@yahoogroups.com, "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" !
> > >
> >
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
| Reply via web post | Reply to sender | Reply to group | Start a New Topic | Messages in this topic (6) |
Tidak ada komentar:
Posting Komentar