if form is open then...

You copy the whole function ( everything in the first code box in my first post on the thread.) And put it into a new module as stated in my last post.

And then you simply call it (supplying the name of the form you want to check is open) wherever you need to do the test. (as in the example in the second code box in my first post)
 
you mean, the function would be ISLOADED?
got it, but like they said, it's already there for 2003 and up

but i see what you're saying, i can do that with all the other code that i use?
make it a function and just call it whever i need to use it?

cool!!!!!!!
 
Yep :) The power of programming...use it wisely ;)
 
With great power, comes great responsibility.

All righty, who's up for beers?
 
unfortunately, i'm not even close to being a programmer
i've managed to design a few pretty good databases using minimal code and workarounds
ofcourse, there's a huge amount of macros and queries and if you saw some of the methods i've used - you'd catch a heartattack)))))))))))))

but now i want to learn vb
i self learned everything, access, networking, hardware
and vb is my next project


so ;)
if anyone here has some time on their hands, be my guest and share))))))))))))
 
damn, 2500 posts banana??? craig, i thought your 1500 was bad

you guys live here!!
 
19000???????????? rich???? oh my
are you serious??
yes, i do have a job)))))))))))))
i mean, i've been coming here for years, but i come, get my answers and go

good for you, guys

i mean i understand, this is like a MS Access puzzle for you guys
you know everything about it and it's fun for you to see what questions get posted and realize that you can answer them all

i totally get it
 
let's make a function hehe
19000/(6*365)=8.65 posts a day

not that bad, but still impressive
 
sorry, i can't get over this

AWF should give out ranks and uniforms
 
LOL...well, as you can see, less than 10,000 posts means you're still fairly new around here ;)
 
If you're using Access 2000 or earlier you need to call a function to return true or false when the form is open or not.
Actually that is "If you are using Access 97 or earlier. The CurrentProject.AllForms("FormNameHere").IsLoaded exists in Access 2000 as well (I just tested in Access 2000).
 
How rude, pointing out my ignorance like that Bob ;)

Thanks for the correction. :D
 
LOL...well, as you can see, less than 10,000 posts means you're still fairly new around here ;)

well then, i haven't even been born yet with my 100 something, and me and Rich started around the same time

but all jokes aside, i'm thankful for this site and that there are people out there who don't mind taking the time out answering questions. this site helped me so many times even if i didn't post anything, just reading other people's questions and answers

so my respect to all of you, no matter how many posts, the ones who answer our questions and thank you
 
Indeed - it's probably easiest to remember stuff like version introductions centering around the CurrentProject object being introduced in 2000.
(As it supported various new methods that weren't there before - not least of which the, now, largely taken for granted CurrentProject.Connection etc).

And if ever there's doubt about the introducing version - just go with 2000 lol
It's a fairly safe bet. ;-)

Leigh
(Less than 250 posts - hasn't even been born yet! :-)
 
i have a question about the IsLoaded thing.

if i'm developing a db in AC2000+, and use the .IsLoaded, and then make, say, an mde... does the person i give this mde to use need

1) access installed
2) the correct version installed to work the .IsLoaded?
 
Hi

It's more a case of file format compatability.
Isloaded as a property was only introduced in 2000 (because the AllForms collection was only introduced then).
In theory - use of such code in an earlier version would fail because the object (CurrentProject), collection (AllForms) and property (IsLoaded) aren't valid. They'd raise compile errors - or, at least, in an MDE runtime errors.
However - the issue of file format compatability is such that earlier than 2000 (e.g. Access 97) cannot even open subsequent version file format applications.
Access (and Jet) fundamentally changed to a more XML based structure with 2000. Jet 3.5 to Jet 4 changed in many ways - not least of all the support for Unicode.

So - to answer the question (at last ;-)...
1) Yes - Access must always be installed to run an MDB or MDE. The Runtime exists to service locations where no Retail install exists - but in some form Access is required.
2) A version of 2000 or newer will be required, but not just to allow IsLoaded to function - but for the application you've created to be opened at all.

Generally speaking - newer versions should be capable of reading and opening older versions. The big change that came with both Access 2000 and Access 2007 means that conversion is offered strongly - but isn't required.
The difference comes with MDEs. They also should be readable by subsequent versions, however reference issues can cause them to fail. (References can't be altered or updated in an MDE - so they are what they are at time of compilation on the development machine).
If there's any binary incompatability at all - you can find the 2000 MDE failing to work in, say, a 2003 Access installation.
I've seen them work more often than not. But also not.

Anything not clear - just shout.
 
oh :eek:

so can i make my db into an exe to distribute as a program (as i was originally hoping i could) from access? or am i completely misguided in using access at all? should i be using VB? -eek! *breathe into brown paper bag*

see, the database i'm making is an equine massage database for equine massage therapists (EMT) well, just one at the moment - my partner, LOL.

but we have a greater goal - to have a purpose-built application that can be distrubutable to EMTs via a professional organisations.

now, it is well, known that (not all) horse people can be rather, how shall i say.... incompatible (for want of a better word) with computers, and i would not expect half of them to have access installed at all, let alone latest versions (although i am building in 2007, i started in 2003 and have kept that format). some of them probably wouldn't even have office (maybe MS works?) some would even have a Mac....

*keep breathing into that bag, girl!*

anyway, you all know different people have different computers and use software... i don't need to blow that horn. i was hoping an exe would fix that (at least for most Windows computers).
 
There's no denying it. IMO Access one true Achilles' heel is its distribution of solutions.
As an Office application - there's no denying or complaining that it centers on the concept of "documents". Each MDB can be thought of as a document as Word has and Excel equivalently has Workbooks.
(An actual "Document" is a more precise concept in the DAO object model - we're just talking conceptually here ;-)

Access itself is the EXE which runs these documents.
The awkwardness comes in that each Access solution we create is an application in itself. It fulfills a requirement - and can be extremely different from the other solutions you create.
None the less - there is no single "EXE" solution. An MDB is simply a file. It requires Access to run it.

You'll no doubt have heard that what we do have is the Access Runtime. A distributable version of Access which will run applications but does not offer any interface for creating or altering the design of those MDB applications. (This obviously all applies even more so to MDEs which aren't generally design editable anyway).
Access 2007 offers the Runtime for free. Previous versions required the developer to own the Developer Extentions.
This gives you the rights to create installation packages which contain both a Runtime install of Access and the application you've created (MDB/MDE - or ACCBD/ACCDE).
In this you therefore have included the version of Access in which you developed. Hence not only if they have no Access installation, but even if they have a different version, your application still has the means to run on their system.

Is the Runtime thought of as a nice neat little package solution-wise? Not by many no. But you needn't think of it as clumsy either. Any solution has pre-requisits.
The VB5/6 runtime files are required for such solutions. Plus any data access APIs must be present. For .NET solutions you must have the pretty substantial .NET framework installed.
The runtime is just another instance of this - but frowned likely upon because of the duality of Access and your application MDB being required and thought of as separate. (IT Depts generally frowning on Access anyway - even though the Runtime doesn't offer that which they fear most - end user freedom to wreck havok with applications dotted everywhere).

So you can take that paper bag from your mouth.
Access does have distribution solutions (a free one if you're using 2007).
Are they as seemless as other development environments? Not necessarily. Though it can all be wrapped up in one (apparently seemless) installation package.

But you gain with Access in other areas that the power of others. You just can't beat it for Rapid Application Development. And its range of data sourcing and inherent binding is just fantastic.

Horses for courses - and the tool you know is usually the best one for the job. :-)

Cheers.
 

Users who are viewing this thread

Back
Top Bottom