browseto nightmare

[hilmi123]

Hi all,

First post, but long time browser.

I have been using browseto over the years with mostly a good outcome, however I have now encountered some strange behaviour.

I have a button which onclick changes to a different form. I can make this work fine, however on the onclick before the browseto command I have some vba code to check that all data on the form is correct before moving on.

The vba code is very simple, eg

If Text52 < 0 And Text61 > 0 Then
P1answer = MsgBox("You have put different sign powers, do you want to edit?", vbQuestion + vbYesNo + vbDefaultButton2, "TEST")
If P1answer <> 7 Then
Exit Sub
End If
End If

Very simple stuff, however code as simple as that will cause the browseto to runtime 6054 error.

If someone clicks "no", it results in a runtime error 6054.

If someone clicks "yes", then tries to click the button again, and then clicks "no", it works second time as intended.

I have tried simplifying the code to things a simple as if 1>0 etc, however it seems any statement seems to trigger a browseto error on this form.

Any ideas?

[NeoPa]

Hi there, & welcome to Bytes.com.

Let me start by pointing out that 6054 is an error code. With an error code you will always have the message that code represents, which makes the error make sense to anyone trying to help. That makes life easy, which is why it's always provided.

Your further explanation discusses what happens when the code is run again - yet doesn't explain the logic you're using that makes that possible.

I don't see what's wrong here, but I also only see a fraction of what I need to in order to understand what it is you should be explaining to me (us).

At no point does the code reference, or illustrate, any interaction with BrowseTo.

[hilmi123]

Hi NeoPa,

Let me try to explain further.

"let me start by pointing out that 6054 is an error code. With an error code you will always have the message that code represents, which makes the error make sense to anyone trying to help. That makes life easy, which is why it's always provided."

The error code I have uploaded an image to illustrate, it suggests the path to the browsed form is incorrect.

This is not the case. As I mentioned, if I remove the simple code that has no bearing on the path, the browseto works fine.

Even if I leave the code in, it works if I click the button which references the browse to code on the second attempt.

"Your further explanation discusses what happens when the code is run again - yet doesn't explain the logic you're using that makes that possible."

So I have a button, when the button is clicked, it will do some checks on the data on a subform, and if all is ok, it will change the form in the subform to a different one. However if the data is not correct, it will show a prompt to the user to check the data. If they select that they are happy with the data, then the VBA will attempt the browseto, at this point the error 6054 will appear. If the user opts to change the data, but actually does nothing, then when then the data check prompts shows again (because the data is still questionable), if the user opts this time to say the data is fine, the browseto code is used and it works without any errors.

"At no point does the code reference, or illustrate, any interaction with BrowseTo."

This is the problem Im trying to fix. The browseto works in isolation, but not when used in certain mundane situations.

For reference, here is the browseto Im using.

DoCmd.BrowseTo ObjectType:=acBrowseToForm, _
ObjectName:="Patients", _
PathToSubformControl:="Main Menu.NavigationSubform", _
WhereCondition:="[Patient ID] =" & Me.PatientID, _
DataMode:=acFormEdit

This all suggests there is nothing wrong with the code per se, but there is a bug in Access. What Im looking for is either some help understanding browseto command or a work around, does anyone have an ideas?

[isladogs]

In over 20 years of using ACCESS, I cannot recall ever using BrowseTo in my own code.
Please can you explain what you are using it for. There may well be another/better approach.

[hilmi123]

isladogs,

I have a navigation set up with buttons on the left side.

The "main menu" is always open, and the changeable subform is "NavigationSubf orm".

So for example lets imagine I am on form x and I want to go back to the "home" form for the NavigationSubfo rm, I would use a browseto command to change the form loaded in the NavigationSubfo rm.

The problem is, if you search you will find the browseto command is at best buggy, but basically not working. You can have it working, and then change something completely unrelated and then it will stop working. I noted on this forum there are countless examples.

[NeoPa]

Hilmi123:
The error code I have uploaded an image to illustrate, it suggests the path to the browsed form is incorrect.

Please don't do it that way. Anyone reading this would have to link to the image file just in order to understand the question. That isn't cool. Many can't even do so due to restrictions - especially if looking from a work environment - but even if they could it's not everyone else's job to work out what the question should be.

Nevertheless, we do at least have an error message now :

Access Error:
Run-time error '6054':

The macro action BrowseTo requires a valid Path argument. A valid Path argument is of the form: MainForm1.Subfo rm1>Form1.Subfo rm1

I struggle to work out what it's trying to say - but one thing is very clear :
It requires a valid Path argument. Except of course there is no Path argument from what I can see. I assume it must be referring to the PathtoSubformCo ntrol argument. I admit to being a little confused by the format indicated as required within the error message but I would lay money it's not going to like a space in the name without [] around it. That's pretty much a given. What else it's trying to say confuses me. Luckily I don't use it myself but I agree that some better explanation and clearer instructions would be helpful.

Hilmi123:
This all suggests there is nothing wrong with the code per se, but there is a bug in Access.

I disagree. I think it indicates you have a limited understanding of the tools you're trying to use. No great shame there - I find it very confusing myself. However, we're a long way from that statement at this point as far as I can see. Fix the obvious errors first then think about Access being wrong. I'll support "Access explains things unhelpfully at times.", but that's as far as I see for now.

So, from all I've seen so far and I've read to the end at this point, you have a main Form called [Main Menu]. On this main Form you have a Subform Control named [NavigationSubfo rm] and your intention at different stages of your process is to show different Form objects within this same Subform Control on your main Form.

Hilmi123:
The problem is, if you search you will find the browseto command is at best buggy, but basically not working. You can have it working, and then change something completely unrelated and then it will stop working. I noted on this forum there are countless examples.

As IslaDogs hinted at, there are better ways of handling what you want to do. Generally speaking I avoid macro actions where possible - even when instigated via DoCmd. They can be really useful to have available but where options exist to manage things via the objects themselves I prefer to use that approach.

Your asking of questions may leave a bit to be desired but I'm seeing a level of programming competence such that this shouldn't frighten you. Subform Controls have three very important Properties beyond their names - [SourceObject], [LinkChildFields] & [LinkMasterField s]. By playing with these you can roll your own code to switch the Forms used within a Subform Control. That's how I'd do it. Obviously (I hope.) be very careful of how you use names of objects. If you have to include spaces then you'll have to learn how to refer to them properly. Avoid spaces in names for an easier life.

Sorry for the long post - but you've asked an interesting question and it deserves a detailed answer.

[hilmi123]

Hi NeoPa,

Thanks for trying, but I dont think you understand.

In reality this is a very simple situation.

The code to change the form in navigationsubfo rm works in some situations and not others. The factor that makes it not work is the code that is running before the BrowseTo cmd.

Eg if there is a dialogue box in my case.

So this works

DoCmd.BrowseTo ObjectType:=acBrowseToForm, _
ObjectName:="Patients", _
PathToSubformControl:="Main Menu.NavigationSubform", _
WhereCondition:="[Patient ID] =" & Me.PatientID, _
DataMode:=acFormEdit

If Me.Text74 = 0 And Forms("Main menu").Text242 > 42 Then
' R no add
Ranswer = MsgBox("Are you sure blah blah", vbQuestion + vbYesNo + vbDefaultButton2, "PMS")
If Ranswer <> 7 Then
Exit Sub
End If
End If
 
DoCmd.BrowseTo ObjectType:=acBrowseToForm, _
ObjectName:="Patients", _
PathToSubformControl:="Main Menu.NavigationSubform", _
WhereCondition:="[Patient ID] =" & Me.PatientID, _
DataMode:=acFormEdit
 
 

That does not work, it results in the RTE 6054. The error also be triggered by running any kind of DAO.

[PeterTheme]

Hi Hilmi123
My thought is that Me.PatientID may not be set correctly and the PathError is just misleading. You may want to try using aTempvars in place of the Me.PatientID.

Looking at the name of the Navigation form you appear to be using the Navigation control. On the "Data" tab of your Navigation buttons you will find properties "Navigation Target Name" and "Navigation Where Clause" so you can avoid using BrowseTo. You would need to set DataMode in the form Open or Load event.

I only occasionally use BrowseTo on my Navigation forms if the Button data settings won't provide sufficient control.

The only bug I have found in Navigation controls, that was acknowledged by Microsoft, was in 2010 runtime version. It only failed when there were 2 rows of horizontal navigation buttons. It worked fine in full Access.

[NeoPa]

Hilmi123:
Thanks for trying, but I dont think you understand.

In reality this is a very simple situation.

Excellent. You seem to be understanding the situation better now. I can't understand what you're saying until what you're saying starts to make some sense & include the information I need in order to understand what you're saying.

It's a simple situation too. Excellent. I'm sure that sometime soon you'll manage to explain it clearly then. All the clues as to what you need to do in order to make sense are in my earlier posts. I'm sure we can make some progress soon if you read what I say and post something that makes your situation clear.

Alternatively, if you continue simply to repeat what we already know to be very unclear then I will stay confused and will not be able to help you further.