Are you using a Library?

Hi Thomas, No, but I now know the problem. I will explain shortly.  'John

I was trying to create a form but I can't with accde.  john

Yep, that sounds correct.
A few of us have been having problems with .accde and libraries lately.

John I think the problem is between creating a form in the development environment and creating/using one at runtime. An accde is meant to be the compiled version of your application, you do not use it to create or modify Access objects such as designing a new form. The forms and reports need to have been created in the accdb and then compiled into the accde.

Now, if your app is making use of VBA such as DoCmd.CreateForm or CreateControl to dynamically create Access objects at runtime then that's a different matter and worth looking at. So in this case, if you were trying to create the form itself, then you'd expect that limitation if trying to run it in the accde.

John's is an interesting experiment; one I've planned for the future WIGTI (when I get to it). Before running a report, in my old RAD (non-Access) systems, I was used to asking a variety of questions like: queue the job, what printer, what customer (if not all), what date range, etc. It would be nice in Access to create such a form before a report runs to ask those questions and then spawn the report, or have subroutines of the report itself ask those questions in a created form, on the fly, so as to not have hundreds of little forms asking simple and often redundant questions for every report. If this can't be done in an .accde via VBA...???

It's funny you bring up library files. That's going to be an upcoming Developer lesson. I've got some cool library techniques that I've recently perfected myself.

And yep, Alkan's got the important distinction right here: an ACCDE is fine for running the application, but it isn't the place to create or modify Access objects at runtime. If you want a reusable report-parameter interface without maintaining hundreds of tiny forms, a prebuilt generic dialog form can handle that very nicely. You can configure its labels, controls, defaults, and options in code, then open the appropriate report based on what the user selects.

Hi Thomas, I think my problem was because I am trying to create forms within the Accde. It works properly as an accdb file. It did make the Accde file but it would not create files because it is not allowed BECAUSE it is an ACCDE file. John Does that make sense?

John The important thing is that you caught it. Professional blind spots happen to the best of us. I remember one time when I needed to disable a text box after an update. I was convinced I had already set it in the Property Sheet, and I nearly drove myself crazy trying to find the damn setting. It wasn't until I went to grab a coffee that I laughed to myself and thought, "Wait a second, Alkan... shouldn't you be doing that in VBA?" I remember going back to my desk shaking my head at myself.
Sometimes, when we're too focused on the end goal, we overlook things we already know and end up wasting time. You're definitely not the first, and you won't be the last, don't sweat it.

John If I were part of the Access team, I would argue that users can't create forms, reports, modules or macros via the "Document Window". However, I should think VBA could, even in an .accde.

I've thought about, but not yet done, Richard's idea of a generic form, then having two tables, one to define all the questions for an application module, and then another for the questions to ask for a given form. Kind of like how I do Jobs and Menus now. Define a job (form, report or macro, open a table) and then where that Job sits in the menus. With luck I could make this form work like the more hard coded ones to use the Validation table and do searches via the Search forms (what customer?, look up in the Customer Search Form and pass the ID back).

Actually, you can create forms in an ACCDE library file and use them. There's a little trick to it, and it takes a bit of explanation, so I'm going to cover it in the next Developer class.

Richard You are completely right. There are a few standard ways to tackle this, such as using a generic form where controls are toggled through VBA, or leveraging an external template .accdb. But the specific trick you mentioned definitely caught my attention and brought back a level of genuine excitement I haven't felt in this space for quite some time. Thank you for sharing your expertise and insight. I'm really looking forward to this lesson.

Hi Rick, I look forward to it.  I am finishing up an application that creates a form in another database, lets the user pick the table, uses Rick's feature to resize the fields, added buttons to resize the fields, let's the users pick colors, and reorders the fields and has filtering on every field. It is saved in the Database where the calling table is. John