Prev: is this valid xml for a custom QAT
Next: Edanmo's Storage Class
From: Albert D. Kallal on 31 Jul 2010 16:15
"Roger" <lesperancer(a)natpro.com> wrote in message
news:3afd39d6-0919-46ff-8945-0765b2ecd527(a)g35g2000yqa.googlegroups.com...

> if I start an MDB with the runtime switch, it's because I want to test
> in runtime mode all the time, not just some of the time
> so you may be correct, but spawning a new access object from within a
> runtime environment should behave the same as
> as spawing it with the actual runtime
>

Unfortanatly, it don't work that way.

Remember, you are using object automation to create a running instances of
<insert ANY com program here>

So, you mean word is also going to start in runtime mode? or perhaps
Outlook, or maybe you are launching an instance of AutoCad in runtime mode?
(oh, wiat,t they don't have a runtime mode!).

You are simply in code creating an instance of a running object which in
your case happens to be access. You can use windows scripting, or word, or
excel to also create that running instance of access using the createojbect
command.

Access itself has absolute ZERO knowledge about the program that is
creating the instance of Access.

> and if I shell out a second copy of access, how can I be sure that
> GetObject(,"Access.Application") will use the correct copy, I could
> have a couple of running copies of access ?

Yes, the above is an correct assumption.
I believe that GetObject will return the most recent instance by default,
but I can't say I tested this concept in production code. You have have to
try some things out.

Perhaps you can add some code to get the window name or some such.

Since access does not support automation with a file name specifed, then
this quite much removes use of createobject().

This restriction exists for any automation client attempting to create an
running instance of access in runtime.

I unfortunately don't have any better suggestion then trying something based
on shell().

Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada


From: Roger on 1 Aug 2010 08:42
On Jul 30, 2:45 pm, "Albert D. Kallal" <PleaseNOOOsPAMmkal...(a)msn.com>
wrote:
> Unfortunately the runtime environment does not support automation or you
> creating a new instance of access.
>
> In fact to be a little bit more specific here, is what happens is if you
> launch the access runtime without any file name supplied, then it's simply
> shuts down.
>
> So in your code when you create the access application, it does get created,
> but then since no file name was supplied when it was opened, then it
> instantly shuts down. (and in fact when you use automation code, you
> actually don't have the ability to supply that file name when you create the
> instance of access)
>
> What this means is in a runtime environment, you'll have to use the shell
> command and shell out with a command line prompt to launch another instance
> of access, I believe you can then still use GetObject(,"Access.Application")
> to get at that running instance in your current code.
>
>
>
> > it works fine on my development system, even when I use the
> > access2007 /runtime switch
>
> Right, you are starting the current application with the runtime switch, but
> the creation of the new access application in your code is NOT using the
> runtime switch.
>
>
>
> > so can I / should I be able to do this with the access2007 runtime ?
>
> Actually you can't use that code, but as mentioned you should be able to
> cobble together something that uses the shell() command.
>
> Albert D. Kallal  (Access MVP)
> Edmonton, Alberta Canada
> Pleaseno_Spam_kal...(a)msn.com

I created this function
using the full version, even though the shell command opened db3, the
getObject() call creates a second copy

which means, when using the runtime, I have the same problem (can't
create activex component)

I wonder why the full version isn't detecting that a copy of db3 is
already running ?

Public Function t3()
Dim obj As Access.Application
Dim strCmd As String
Dim strPath As String

On Error GoTo ferr
strPath = "\\dev01\access\development\db3.mdb"
strCmd = "C:\Program Files (x86)\Microsoft Office\OFFICE12"
If (Dir(strCmd, vbDirectory) = "") Then
strCmd = "C:\Program Files\Microsoft Office\OFFICE12"
If (Dir(strCmd, vbDirectory) = "") Then
MsgBox "Can't find access2007"
Exit Function
End If
End If

strCmd = strCmd & "\msaccess.exe"
strCmd = strCmd & " " & Chr(34) & strPath & Chr(34)
Shell strCmd
MsgBox 1
Set obj = GetObject(strPath, "Access.Application")
MsgBox 2
With obj
.Visible = True
.RefreshTitleBar
MsgBox "db3"
End With
fexit:
Exit Function
ferr:
MsgBox "err " & Err.Description
End Function
From: Roger on 1 Aug 2010 09:32
On Aug 1, 6:42 am, Roger <lesperan...(a)natpro.com> wrote:
> On Jul 30, 2:45 pm, "Albert D. Kallal" <PleaseNOOOsPAMmkal...(a)msn.com>
> wrote:
>
>
>
>
>
> > Unfortunately theruntimeenvironment does not support automation or you
> > creating a new instance of access.
>
> > In fact to be a little bit more specific here, is what happens is if you
> > launch the accessruntimewithout any file name supplied, then it's simply
> > shuts down.
>
> > So in your code when you create the access application, it does get created,
> > but then since no file name was supplied when it was opened, then it
> > instantly shuts down. (and in fact when you use automation code, you
> > actually don't have the ability to supply that file name when you create the
> > instance of access)
>
> > What this means is in aruntimeenvironment, you'll have to use the shell
> > command and shell out with a command line prompt to launch another instance
> > of access, I believe you can then still useGetObject(,"Access.Application")
> > to get at that running instance in your current code.
>
> > > it works fine on my development system, even when I use the
> > > access2007 /runtimeswitch
>
> > Right, you are starting the current application with theruntimeswitch, but
> > the creation of the new access application in your code is NOT using the
> >runtimeswitch.
>
> > > so can I / should I be able to do this with the access2007runtime?
>
> > Actually you can't use that code, but as mentioned you should be able to
> > cobble together something that uses the shell() command.
>
> > Albert D. Kallal  (Access MVP)
> > Edmonton, Alberta Canada
> > Pleaseno_Spam_kal...(a)msn.com
>
> I created this function
> using the full version, even though the shell command opened db3, thegetObject() call creates a second copy
>
> which means, when using theruntime, I have the same problem (can't
> create activex component)
>
> I wonder why the full version isn't detecting that a copy of db3 is
> already running ?
>
> Public Function t3()
>     Dim obj As Access.Application
>     Dim strCmd As String
>     Dim strPath As String
>
>     On Error GoTo ferr
>     strPath = "\\dev01\access\development\db3.mdb"
>     strCmd = "C:\Program Files (x86)\Microsoft Office\OFFICE12"
>     If (Dir(strCmd, vbDirectory) = "") Then
>         strCmd = "C:\Program Files\Microsoft Office\OFFICE12"
>         If (Dir(strCmd, vbDirectory) = "") Then
>             MsgBox "Can't find access2007"
>             Exit Function
>         End If
>     End If
>
>     strCmd = strCmd & "\msaccess.exe"
>     strCmd = strCmd & " " & Chr(34) & strPath & Chr(34)
>     Shell strCmd
> MsgBox 1
>     Set obj =GetObject(strPath, "Access.Application")
> MsgBox 2
>     With obj
>         .Visible = True
>         .RefreshTitleBar
> MsgBox "db3"
>     End With
> fexit:
>     Exit Function
> ferr:
>     MsgBox "err " & Err.Description
> End Function- Hide quoted text -
>
> - Show quoted text -

I got it working using
Set obj = GetObject(, "Access.Application")

but it turns out that some of the things I wanted to do
with the object (visible / run) aren't working
With obj
.Visible = True
.RefreshTitleBar
.RunCommand acCmdAppMaximize
.Run "editHandover", "H", 999
End With

so I'm passing the function to "run" as
part of the command line, and I'm using vbMaximizedFocus
to get what I need, so the final version is

Public Function t3()
Dim strCmd As String
Dim strPath As String

On Error GoTo ferr
strPath = "\\dev01\access\development\db3.mdb"
strCmd = "C:\Program Files (x86)\Microsoft Office\OFFICE12"
If (Dir(strCmd, vbDirectory) = "") Then
strCmd = "C:\Program Files\Microsoft Office\OFFICE12"
If (Dir(strCmd, vbDirectory) = "") Then
MsgBox "Can't find access2007"
Exit Function
End If
End If

strCmd = strCmd & "\msaccess.exe"
strCmd = strCmd & " " & Chr(34) & strPath & Chr(34)
strCmd = strCmd & " /cmd editHandover|H|99"
Shell strCmd, vbMaximizedFocus

fexit:
Exit Function
ferr:
MsgBox "err " & Err.Description
End Function
From: Salad on 1 Aug 2010 10:25
Albert D. Kallal wrote:
> Unfortunately the runtime environment does not support automation or you
> creating a new instance of access.

I'm curious about that statement. Does that also include Word, Outlook,
and Excel?
From: Albert D. Kallal on 1 Aug 2010 14:18
"Salad" <salad(a)oilandvinegar.com> wrote in message
news:zfCdnU9tHNNIHsjRnZ2dnUVZ_u-dnZ2d(a)earthlink.com...
> Albert D. Kallal wrote:
>> Unfortunately the runtime environment does not support automation or you
>> creating a new instance of access.
>
> I'm curious about that statement. Does that also include Word, Outlook,
> and Excel?

Well, READ carefully again what I further clarify in those posts.

In fact as I stated, access doesn't know or care what language is being used
here, from visual basic scripting, visual basic .net, FoxPro or word, or
even another copy of access running, the language or what application here
is not really an access particular issue in terms of automation.

To state again: The access runtime shuts down if you don't supply a file
name when you start it up. This behaviors been this way for very long time.
If you think about this, it kind makes sense that if you click on the access
runtime icon, because there is no user interface and there is no ability to
open up a file, it would be rather quite silly to leave a copy of the
application running in memory. If you clicked on that access icon, you would
be launching multiple copies of access each time you click, and because the
runtime has no user interface, you would have no way of shutting down the
application.

So the default behavior of the runtime is that, when you launch it or create
an automated instance of the runtime, since there's no file name supplied,
the application then simply shuts down.

In effect it means that when you launch the runtime, you must supply in
access file or database to open when you do so, and then the copy of access
will remain running.

The core problem or issue here is of course, is that when you automate an
instance of access (createObject), it's not possible to supply the file name
to be opened. Therefore logical reasoning and intellectual deduction makes
one realize that this behavior means you can't use automation to create a
running instance of access in this case.

So this has absolutely nothing to do with behavior of word or outlook or
excel or any other application that you attempt to launch. (they will all
launch and run just fine even when you use the access runtime).

If you're willing to think through all of the results of this behavior
yourself, I only need to tell you one thing:

The access runtime shuts down when it's launched without a file name
supplied for it to work with.

Everything else that follows is a result of the above information can then
be intellectually realized and thought out by you.
Of course the second piece of the puzzle is that when you automate access,
you can't supply a file name, therefore logic dictates you can't use
automation this case can you?

So the limitation we are witnessing here is the results of a particular
behavior of the access runtime, and that behavior is simply that acess shuts
down when no file name is supplied.

Albert K.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: is this valid xml for a custom QAT
Next: Edanmo's Storage Class