RunCommand acCmdFind causes "Error 2046: ... Find isn't available now"

[JohnM77 via AccessMonster.com]

I have a main form (frmMain) that loads when the database (Access 2003) is
opened. The frmMain contains a series of commandbuttons that open additional
forms using statements such as the following:

Private Sub cmdOpenSalesOrdersForm_Click()
DoCmd.OpenForm "frmSalesOrders", acNormal, , , , acDialog
End Sub

The frmSalesOrders contains a commandbutton that is supposed to Setfocus on
an embedded Subform (subTable) and then invoke the Find dialog using the
following statements:

Private Sub cmdFind_Click()
subTable.SetFocus
RunCommand acCmdFind
End Sub

When frmSalesOrders is opened using the button on the main form, the
following error is raised:

Error 2046: Command or action Find isn't available now.

If the same frmSalesOrders form is opened directly from the database window,
the Find button works perfectly. How can I make the acCmdFind command
function properly when I open frmSalesOrder from the frmMain button-click?

I tried googling for solutions, but can't find info directly related to this
issue. Any suggestions are greatly appreciated.

Thanks,
John


is opened in this manner

 

[Jeff Boyce]

You don't mention where your data is, and it all starts with the data!

Is there a chance you are using a "linked table"? I seem to recall issues
with using the Find command with linked data...

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[JohnM77 via AccessMonster.com]

Thanks for your reply, Jeff. The data is in the same database as the forms. I
just discovered that changing acDialog to acWindowNormal acheives what I'm
looking for. After further research, the difference seems to be that acDialog
mode opens the form as a popup, which apparently leave the host form as the
active object. Find apparently won't work on an object that is not currently
active.

http://msdn.microsoft.com/en-us/library/bb225995.aspx

-John

You don't mention where your data is, and it all starts with the data!

Is there a chance you are using a "linked table"? I seem to recall issues
with using the Find command with linked data...

Regards

Jeff Boyce
Microsoft Office/Access MVP

I have a main form (frmMain) that loads when the database (Access 2003) is
opened. The frmMain contains a series of commandbuttons that open

[quoted text clipped - 33 lines]

is opened in this manner

 

[Jeff Boyce]

Thanks for posting back your solution. Someone else someday else will
undoubtedly be looking for an answer to this question, and now they have
one!

Regards

Jeff Boyce
Microsoft Office/Access MVP

Thanks for your reply, Jeff. The data is in the same database as the
forms. I
just discovered that changing acDialog to acWindowNormal acheives what I'm
looking for. After further research, the difference seems to be that
acDialog
mode opens the form as a popup, which apparently leave the host form as
the
active object. Find apparently won't work on an object that is not
currently
active.

http://msdn.microsoft.com/en-us/library/bb225995.aspx

-John

You don't mention where your data is, and it all starts with the data!

Is there a chance you are using a "linked table"? I seem to recall issues
with using the Find command with linked data...

Regards

Jeff Boyce
Microsoft Office/Access MVP

I have a main form (frmMain) that loads when the database (Access 2003)
is
opened. The frmMain contains a series of commandbuttons that open

[quoted text clipped - 33 lines]

is opened in this manner

 

[JohnM77 via AccessMonster.com]

Hello Jeff,

Thanks for your help on this issue. The solution that I discovered works for
some cases. However, there are other cases in which I show a form as a dialog
that will return a value to the calling subroutine. In this scenario, my
previous solution fails because the subroutine that calls the dialog form
does not pause and wait for the dialog form to close before it continues on,
using the value returned by the dialog.

It seems that a form must be opened as a "Popup" (property setting, Pop Up =
Yes) in order to cause the calling routine to wait for the dialog form to
close, and popup forms do not allow the Find functions to operate correctly.
Is there a way to allow a form to use the Find functions when the form is
opened as a Popup?

Thanks!
John

Thanks for posting back your solution. Someone else someday else will
undoubtedly be looking for an answer to this question, and now they have
one!

Regards

Jeff Boyce
Microsoft Office/Access MVP

Thanks for your reply, Jeff. The data is in the same database as the
forms. I

[quoted text clipped - 27 lines]

 

[Jeff Boyce]

John

No experience using that approach, but maybe another reader has done that.

Are you "welded" to using the <Find> approach?

Regards

Jeff Boyce
Microsoft Office/Access MVP

Hello Jeff,

Thanks for your help on this issue. The solution that I discovered works
for
some cases. However, there are other cases in which I show a form as a
dialog
that will return a value to the calling subroutine. In this scenario, my
previous solution fails because the subroutine that calls the dialog form
does not pause and wait for the dialog form to close before it continues
on,
using the value returned by the dialog.

It seems that a form must be opened as a "Popup" (property setting, Pop Up
=
Yes) in order to cause the calling routine to wait for the dialog form to
close, and popup forms do not allow the Find functions to operate
correctly.
Is there a way to allow a form to use the Find functions when the form is
opened as a Popup?

Thanks!
John

Thanks for posting back your solution. Someone else someday else will
undoubtedly be looking for an answer to this question, and now they have
one!

Regards

Jeff Boyce
Microsoft Office/Access MVP

Thanks for your reply, Jeff. The data is in the same database as the
forms. I

[quoted text clipped - 27 lines]

is opened in this manner

 

[JohnM77 via AccessMonster.com]

Thanks for your reply, Jeff. I would certainly entertain alternatives. If you
have a suggestion, I'd love to hear about it. I appreciate your help!

-John

John

No experience using that approach, but maybe another reader has done that.

Are you "welded" to using the <Find> approach?

Regards

Jeff Boyce
Microsoft Office/Access MVP

Hello Jeff,

[quoted text clipped - 33 lines]

 

[Jeff Boyce]

John

Your original post included a Find ... but I'm not clear what was being
'found'.

Can you offer a few more specifics on the underlying business need ("why",
rather than "how")? And it might also help to know a bit more about the
underlying data ... it all starts with the data!

Regards

Jeff Boyce
Microsoft Office/Access MVP

Thanks for your reply, Jeff. I would certainly entertain alternatives. If
you
have a suggestion, I'd love to hear about it. I appreciate your help!

-John

John

No experience using that approach, but maybe another reader has done that.

Are you "welded" to using the <Find> approach?

Regards

Jeff Boyce
Microsoft Office/Access MVP

Hello Jeff,

[quoted text clipped - 33 lines]

is opened in this manner

 

[JohnM77 via AccessMonster.com]

Jeff,

I'll try to summarize what I'm trying to do...

As I've discovered, the "RunCommand acCmdFind" statement invokes the Find
dialob box that is inherent to Access (basically a Ctrl-F keystroke). I have
a need to allow the user to perform a Ctrl-F in any datasheet that my program
displays. The program includes a series of Forms that contain Subforms
displaying data from stored queries. The queries contain data related to
inquiries, sales, purchasing, etc., including ID fields and various numeric
and text field-datatypes.

The problem that I've encountered is that the Ctrl-F (or programmatic
equivalent) does not work on datasheet Subforms that have been opened as "Pop
Up" designation. I believe the reason is that "Pop Up" forms are not the true
active object, even though they have focus and otherwise function as a normal
form; it is the calling form (form in which a button_click event loaded the
pop-up form) that remains as the active object. Any attempt to
programmatically invoke the Find dialog (RunCommand acCmdFind) on the pop-up
form raises error 2046, as described in my first post.

So now I'm seeking alternatives to the "RunCommand acCmdFind", in order to
allow users to search for values (numeric or text) within a datasheet
embedded on a pop-up form.

Does that make any sense?

Thanks,
John

John

Your original post included a Find ... but I'm not clear what was being
'found'.

Can you offer a few more specifics on the underlying business need ("why",
rather than "how")? And it might also help to know a bit more about the
underlying data ... it all starts with the data!

Regards

Jeff Boyce
Microsoft Office/Access MVP

Thanks for your reply, Jeff. I would certainly entertain alternatives. If
you

[quoted text clipped - 18 lines]

 

[Jeff Boyce]

John

Let me start by asking you to stop...

If you are displaying datasheets (look like spreadsheets, contains data in
tables), you may be making this much harder for both yourself and your
users. Access tables store data, but Access forms display it. If you or
your users are interacting directly with the data in tables (or datasheets),
you will find (no pun) considerable headaches.

Based on your more complete description, I am still in the dark <g>...

You are still describing "how" you are trying to do something (data sheets,
forms, <Find>, pop-ups, button-click, ...) -- those are all techniques and
features (i.e., "how").

I'm trying to get a better understanding of what business need is supposed
to be getting met. I ask, not out of idle curiosity, but because there may
be ways to accomplish (?something?) that you haven't considered, having been
focusing on the techniques you are describing.

(still) More info, please...

Regards

Jeff Boyce
Microsoft Office/Access MVP

Jeff,

I'll try to summarize what I'm trying to do...

As I've discovered, the "RunCommand acCmdFind" statement invokes the Find
dialob box that is inherent to Access (basically a Ctrl-F keystroke). I
have
a need to allow the user to perform a Ctrl-F in any datasheet that my
program
displays. The program includes a series of Forms that contain Subforms
displaying data from stored queries. The queries contain data related to
inquiries, sales, purchasing, etc., including ID fields and various
numeric
and text field-datatypes.

The problem that I've encountered is that the Ctrl-F (or programmatic
equivalent) does not work on datasheet Subforms that have been opened as
"Pop
Up" designation. I believe the reason is that "Pop Up" forms are not the
true
active object, even though they have focus and otherwise function as a
normal
form; it is the calling form (form in which a button_click event loaded
the
pop-up form) that remains as the active object. Any attempt to
programmatically invoke the Find dialog (RunCommand acCmdFind) on the
pop-up
form raises error 2046, as described in my first post.

So now I'm seeking alternatives to the "RunCommand acCmdFind", in order to
allow users to search for values (numeric or text) within a datasheet
embedded on a pop-up form.

Does that make any sense?

Thanks,
John

John

Your original post included a Find ... but I'm not clear what was being
'found'.

Can you offer a few more specifics on the underlying business need ("why",
rather than "how")? And it might also help to know a bit more about the
underlying data ... it all starts with the data!

Regards

Jeff Boyce
Microsoft Office/Access MVP

Thanks for your reply, Jeff. I would certainly entertain alternatives.
If
you

[quoted text clipped - 18 lines]

is opened in this manner

 

[JohnM77 via AccessMonster.com]

Jeff,

I'm only using datasheets to display data. I use the OnCurrent event of
Subform controls to populate unbound textboxes and comboboxes for data
editing. Commandbuttons are then used to save the edits back to the selected
record in the Subforms. But that's more of the "how". :\

I appreciate you hanging with me on this issue. Beyond knowing that I wish to
use the search dialog in a popup form, perhaps you could specify the
information that would make my scenario more clear, and I'll post it here. My
program is complex, and so I'm trying to avoid clouding the basic question
with extraneous information. Again, thanks for your help. I truly appreciate
your time.

Best regards,
John

John

Let me start by asking you to stop...

If you are displaying datasheets (look like spreadsheets, contains data in
tables), you may be making this much harder for both yourself and your
users. Access tables store data, but Access forms display it. If you or
your users are interacting directly with the data in tables (or datasheets),
you will find (no pun) considerable headaches.

Based on your more complete description, I am still in the dark <g>...

You are still describing "how" you are trying to do something (data sheets,
forms, <Find>, pop-ups, button-click, ...) -- those are all techniques and
features (i.e., "how").

I'm trying to get a better understanding of what business need is supposed
to be getting met. I ask, not out of idle curiosity, but because there may
be ways to accomplish (?something?) that you haven't considered, having been
focusing on the techniques you are describing.

(still) More info, please...

Regards

Jeff Boyce
Microsoft Office/Access MVP

Jeff,

[quoted text clipped - 54 lines]

 

[Jeff Boyce]

John

An example...

You might be working on a system to help folks register for classes. The
"domain" would be education, and would involve "students", "classes" and
"enrollments" (as well as "instructors", "classrooms", etc., but that's
adding unnecessary complexity to a simple example). The "business need" is
to have a way to register students for classes. Before we can get into the
"how", the "what" is needed.

In this example, you'd have data something like (again, a simplistic
example):

tblStudent
StudentID
FName
LName
DOB
... (other student-specific info)

tblClass
ClassID
ClassTitle
ClassDescription
... (other ...)

trelEnrollment
EnrollmentID
StudentID
ClassID
EnrollmentDate
... (other ...)

Does that give you more of an idea of the kind of background/business need
I'm trying to understand?

Regards

Jeff Boyce
Microsoft Office/Access MVP