Click Command not Working (1 Viewer)

[Warreno]

Hi,



I am fairly new to VBA and working with older code created by someone that no longer works with my company. The command click no longer does anything and I am not sure why. I did enable variable declaration, but not sure it helps if its existing code. Added the code below, please help.

Private Sub Command53_Click()
DoCmd.SetWarnings False


 Dim strFilter As String
    Dim strInputFileName As String


    strFilter = ahtAddFilterItem(strFilter, "Excel Files (*.xlsx,*.xls)", "*.xlsx;*.xls")
    strFilter = ahtAddFilterItem(strFilter, "PDF Files (*.pdf)", "*.pdf")
    strFilter = ahtAddFilterItem(strFilter, "Text Files (*.txt,*.csv)", "*.txt,*.csv")
    strFilter = ahtAddFilterItem(strFilter, "All Files (*.*)", "*.*")

    strInputFileName = ahtCommonFileOpenSave( _
                            Filter:=strFilter, _
                            OpenFile:=True, _
                            DialogTitle:="Please Select A File", _
                            Flags:=ahtOFN_HIDEREADONLY)

    If Len(strInputFileName) > 0 Then
        ' Do something with the selected file

Text51.Value = strInputFileName

Else
End If
End Sub

 

[theDBguy]

Hi. Are you getting any errors?

 

[Warreno]

No nothing, the button just doesnt do anything. Before the database was throwing an error because the code was so old and I needed to update it to run with 64 bit to open. Fixed that, but now some parts just dont do anything, and do not throw errors so not sure how to fix it.

 

[Warreno]

I could post the code for the functions if that would help

 

[Uncle Gizmo]

Below is an exact copy of your code with an added line. The added line should cause the button press to produce a message box saying >>> TEST <<<. Add this line to your code exactly as in the example below and report back what happens.

Private Sub Command53_Click()
DoCmd.SetWarnings False

[COLOR="black"][COLOR="Red"]MsgBox " >>> TEST <<<"[/COLOR][/COLOR]

 Dim strFilter As String
    Dim strInputFileName As String


    strFilter = ahtAddFilterItem(strFilter, "Excel Files (*.xlsx,*.xls)", "*.xlsx;*.xls")
    strFilter = ahtAddFilterItem(strFilter, "PDF Files (*.pdf)", "*.pdf")
    strFilter = ahtAddFilterItem(strFilter, "Text Files (*.txt,*.csv)", "*.txt,*.csv")
    strFilter = ahtAddFilterItem(strFilter, "All Files (*.*)", "*.*")

    strInputFileName = ahtCommonFileOpenSave( _
                            Filter:=strFilter, _
                            OpenFile:=True, _
                            DialogTitle:="Please Select A File", _
                            Flags:=ahtOFN_HIDEREADONLY)

    If Len(strInputFileName) > 0 Then
        ' Do something with the selected file

Text51.Value = strInputFileName

Else
End If
End Sub

 

[The_Doc_Man]

I needed to update it to run with 64 bit to open

Here is a part of the issue: Not all code libraries were converted for 64-bit usage. I am familiar with file-type filters for file picker routines but I am unfamiliar with the "aht" prefix. I suspect that somewhere, the code you are fixing has declared an external sub from some library and used that naming prefix to do it. Which is OK, but it would help to see those declarations.

Here is a different question. Was that conversion to 64-bit Office necessary? You see, Access isn't beneficially affected by the 64-bit upgrade. I don't think Word or PowerPoint take any benefit either. Only Excel actually gains the ability to make bigger workbooks and spreadsheets from the switch to 64-bit. But if you don't need 64-bit Excel then you would probably do better to remove 64-bit Office and install 32-bit Office. Both versions are usually on the same distribution disk, or if you downloaded, they are available from the same site. AND both versions run equally well on 64-bit machines. That's what I'm using on my newer machine and have no problems doing so. If you switch to 32-bit Office, then most of the older code libraries have updates to newer versions - and they work in a 32-bit Office environment.

When you are in the code editing screen, you can check references via menu-bar Tools >> References and that will tell you if you have any missing references. After a switch to 64-bit, I would bet that you do.

 

[Warreno]

Here is a part of the issue: Not all code libraries were converted for 64-bit usage. I am familiar with file-type filters for file picker routines but I am unfamiliar with the "aht" prefix. I suspect that somewhere, the code you are fixing has declared an external sub from some library and used that naming prefix to do it. Which is OK, but it would help to see those declarations.

Here is a different question. Was that conversion to 64-bit Office necessary? You see, Access isn't beneficially affected by the 64-bit upgrade. I don't think Word or PowerPoint take any benefit either. Only Excel actually gains the ability to make bigger workbooks and spreadsheets from the switch to 64-bit. But if you don't need 64-bit Excel then you would probably do better to remove 64-bit Office and install 32-bit Office. Both versions are usually on the same distribution disk, or if you downloaded, they are available from the same site. AND both versions run equally well on 64-bit machines. That's what I'm using on my newer machine and have no problems doing so. If you switch to 32-bit Office, then most of the older code libraries have updates to newer versions - and they work in a 32-bit Office environment.

When you are in the code editing screen, you can check references via menu-bar Tools >> References and that will tell you if you have any missing references. After a switch to 64-bit, I would bet that you do.

The conversion was done before I started here. I ended up just needing to add PtrSafe to a few lines of code so that it would run.



When I look at references it is only showing four as selected. VB for Apps, Microsoft Access 15.0 Object Library, OLE Automation, and MO 15.0 Access Database engine Object Library

 

[Warreno]

Below is an exact copy of your code with an added line. The added line should cause the button press to produce a message box saying >>> TEST <<<. Add this line to your code exactly as in the example below and report back what happens.

Private Sub Command53_Click()
DoCmd.SetWarnings False

[COLOR=black][COLOR=Red]MsgBox " >>> TEST <<<"[/COLOR][/COLOR]

 Dim strFilter As String
    Dim strInputFileName As String


    strFilter = ahtAddFilterItem(strFilter, "Excel Files (*.xlsx,*.xls)", "*.xlsx;*.xls")
    strFilter = ahtAddFilterItem(strFilter, "PDF Files (*.pdf)", "*.pdf")
    strFilter = ahtAddFilterItem(strFilter, "Text Files (*.txt,*.csv)", "*.txt,*.csv")
    strFilter = ahtAddFilterItem(strFilter, "All Files (*.*)", "*.*")

    strInputFileName = ahtCommonFileOpenSave( _
                            Filter:=strFilter, _
                            OpenFile:=True, _
                            DialogTitle:="Please Select A File", _
                            Flags:=ahtOFN_HIDEREADONLY)

    If Len(strInputFileName) > 0 Then
        ' Do something with the selected file

Text51.Value = strInputFileName

Else
End If
 End Sub

Yes, it does not say test when I click on it

 

[The_Doc_Man]

Since you had to go in and "diddle" things, it is possible that the control's link to its events got broken somehow. Visit the event properties list for the control and re-assert that it will be using a click-event routine. THEN go back into the class module and check for having TWO cases of "Private Sub Command53_Click." If you do, one of them will be a stub and the other will be your code. Delete the stub. Then try it.

 

[theDBguy]

Also, just something to consider. The API method you're using was necessary before; but now, Access has the FileDialog Object, which you can use as a replacement. It's not affected by a change to 64-bit environment. Just a suggestion...

 

[theDBguy]

Oh, and one more thing. Take a look here and go to the "Stepping Through Code" section. It might help you find the problem with your code. Good luck!

 

[Warreno]

Since you had to go in and "diddle" things, it is possible that the control's link to its events got broken somehow. Visit the event properties list for the control and re-assert that it will be using a click-event routine. THEN go back into the class module and check for having TWO cases of "Private Sub Command53_Click." If you do, one of them will be a stub and the other will be your code. Delete the stub. Then try it.

Thanks, that did work for all but Command 53. So the other 3 buttons that were not working, now work. Not sure whats going on with that button though. I tried deleting the code completely, saving, and going back to readd the event and code but still does nothing. Should I just get ride of it and setup a browse to select and upload a file?

 

[Warreno]

Oh, and one more thing. Take a look here and go to the "Stepping Through Code" section. It might help you find the problem with your code. Good luck!

It doesnt throw an error so this part doesnt help too much. It just doesnt do anything.

 

[Warreno]

Also, just something to consider. The API method you're using was necessary before; but now, Access has the FileDialog Object, which you can use as a replacement. It's not affected by a change to 64-bit environment. Just a suggestion...

This may be very helpful. I will take a look at re-writing the code and see if that works. Someone way before me wrote it and had notes from windows 95.

 

[theDBguy]

It doesnt throw an error so this part doesnt help too much. It just doesnt do anything.

Hi. There's several types of errors. If you're not getting any error messages, then you may have a logic error. Stepping through the code should help you catch those as well. If you look at the linked article, there's a section on how to "pause" code, so you can step through it. Hope it helps...

 

[Gasman]

It doesnt throw an error so this part doesnt help too much. It just doesnt do anything.

If you were to put a breakpoint in the code or put a MSGBOX as Tony did for your other code, that would show you whether you are even going into the code.

So the Debugging subsection would also prove valuable.?

Plus how did you put the code back in.?
Explain the steps in detail please.?

 

[Warreno]

If you were to put a breakpoint in the code or put a MSGBOX as Tony did for your other code, that would show you whether you are even going into the code.

So the Debugging subsection would also prove valuable.?

Plus how did you put the code back in.?
Explain the steps in detail please.?

I didnt write any of the code, I just inherited it. Most of it is an older terminology than I have seen previously. I was trying to figure out how he linked the various parts. It does not look like it is linking to anything to open a box to search for a file at all but I am told it did.



I just wrote out new code and made sure all the links were working and it updated the appropriate fields.

 

[Warreno]

Also, just something to consider. The API method you're using was necessary before; but now, Access has the FileDialog Object, which you can use as a replacement. It's not affected by a change to 64-bit environment. Just a suggestion...

I went through and updated the code with the FileDialog Object and updated the library to include the missing pieces and it works great!

 

[theDBguy]

I went through and updated the code with the FileDialog Object and updated the library to include the missing pieces and it works great!

Hi. Congratulations! This would at least avoid problems in the future when using the API (because you won't be using API anymore). Good luck with your project.

 

[gemma-the-husky]

if that is your code, then it doesn't actually do anything. (other than show it in the text box)

it ought to let you browse your HDD and pick a file - but then you have to do smoething with the file you pick, and you aren't....