Access Crashes

I ran through the command button's code in debug mode.  Access actually crashes after the End Sub line.

Tried creating a new button.  No change.

Hi, miqrogroove.

Can you share the code and routines for declaring, opening, and disposing of your Media Player object?

There is actually no code to do that.  The WMP control is saved in the form.  However, here are some of the methods I used to load tracks into the control after the form is opened:

Set Player = Me.WindowsMediaPlayer.Object

Player.settings.autoStart = True
Player.URL = "filename.asx"
Player.currentPlaylist.appendItem Player.newMedia("filename.wma")
DoEvents
If Player.currentPlaylist.Count > 2 Then
    Player.currentPlaylist.RemoveItem Player.currentPlaylist.Item(0)
    DoEvents
End If
Player.Controls.playItem Player.currentPlaylist.Item(Player.currentPlaylist.Count - 1)
DoEvents


Like I said earlier, the only thing that causes the crash is clicking a command button that closes the form.  The only fix I found so far is to delete that button and not use it :)  Since I did that, there have been no crashes.  But, the question is, can I use that button somehow?

Is Event Log info useful?  Maybe it's a bug in Access?

Description:
Faulting application msaccess.exe, version 11.0.6355.0, stamp 40aa97a8, faulting module msaccess.exe, version 11.0.6355.0, stamp 40aa97a8, debug? 0, fault address 0x000b6dee.

I'm sorry-I'm not familiar with this control (not sure how to add it to an Access form). But, per this URL, the code to stop the player from playing is:

     WindowsMediaPlayer1.Controls.stop

I'm wondering if the If logic would make closing your form safe, e.g.:

      WindowsMediaPlayer1.Controls.stop
      If WindowsMediaPlayer1.playState <> wmppsPlaying Then
           DoCmd.Close acForm, Me.Name
      End if

And if the playing status/stop items don't prevent the crash when you close your form, can you cycle through the various options by typing "WindowsMediaPlayer1." and seeing if there is some method that would "disengage" the control? Or it might be under "WindowsMediaPlayer1.Controls."

Sorry, the URL is:

     http://www.vbcity.com/forums/faq.asp?fid=36&cat=General

This EE post provides an alternate way to play music files:

     https://www.experts-exchange.com/questions/20926980/Load-Play-and-Pause-wav-file-with-embedded-Windows-Media-PLayer-in-Form.html

The playing status actually doesn't affect the crash.  If I play something and press stop before clicking the command button, then the crash still happens.

I know what you mean about trying to "disengage" the control.  One thing I will try is:

Set Me.WindowsMediaPlayer.Object = Nothing

I'm not sure if that is valid.  But it is still so strange that the x button in the title bar closes the form smoothly every time.

New test results:

If I play a file and then close the form using the Immediate window:

DoCmd.Close acForm, FormName

Then it doesn't crash.  This seems to reinforce the result I had earlier where Access was crashing on the "End Sub" line of the command button's event routine.  So, there seems to be some sort of problem with the Access heap.  When the form and WMP are loaded with a playlist, then closing the form with a subroutine doesn't work properly.

The next thing I will try is calling a public Module routine from the command button's sub instead of running DoCmd.Close directly inside of it.

Still same problem.

So what is it about having a subroutine on the heap that is causing an executable fault?

Tried using the /decompile parameter.  No change.

Not sure. If you add "Exit Sub" right before the "End Sub" of your button's routine, does it help? By the way, how do you add this control to an Access form, so I can try it?

The Windows Media Player control is available in the Forms toolbox.  It is at the bottom of the list.

I was able go to my Access top menu and Insert/ActiveX Control/Windows Media Player. When I right-click on that control in Design View and choose Build Event, I'm taken to the VB editor window, to a sub named "ActiveXCtl1_OpenStateChange(ByVal NewState As Long)". Do you have the same control, or a different version?

It sounds the same.  Build Event gives me a different sub.  I get WindowsMediaPlayer0_Updated(Code As Integer)
The control class is WMPlayer.OCX.7

Mine is msdxm.ocx. I am noticing that jumping back and forth between the Access form window and the actual Visual Basic code when intermittently crashes Access. It only happens when I'm working in the ActiveXCtl1_Exit code window, for example with:

     ActiveXCtl1.Object = Nothing


I also noticed something else. I put a Msgbox "Exit" code line in the ActiveXCtl1_Exit event. If I run the form and click on anything but the WM player (e.g. the command button, the WebBrowser control, etc.), and then close the form, I get no message box. However, if I click on the WM player (I'm not opening any files with it, am just clicking on it), and then close my form, I get the "Exit" msgbox popup prior to the form's closing.

In other words, if the WM player HAS THE FOCUS when I close my form, I get the Player's Exit event msgbox. So, I wonder, if you were to place your initially-posted exit code in your WM control's WindowsMediaPlayer0_Exit(Cancel As Integer)
 event if it would stop Access from crashing. E.g.:

     Set Player = Me.WindowsMediaPlayer3.Object
     Player.Controls.stop
     DoEvents
     Player.URL = ""
     DoEvents
     Player.Close
     DoEvents
     Set Player = Nothing

And in your Exit button's Click event try actually disabling the WM Player control before exiting the form:

     WindowsMediaPlayer0.Enabled = False    
     DoCmd.Close acForm, Me.Name

The WMP control will not have focus when the command button is used, because the command button will have focus.

I can try disabling the control, sure.  I'm still suspecting memory management is the cause though.

Understood about the focus; just wanted to convey the WM Player's Exit event will fire every time the control had focus and subsequently loses it. So putting your WM tear-down code in the WM Player Exit event may be successful, whereas it didn't help us when placed in the command button's code. There's little doubt it's a memory conflict issue, similar to what was experienced here (https://www.experts-exchange.com/questions/21460718/Multiple-bookmarks-selection-in-datagrid-vb6.html), but I'm unclear how to neutralize the passing/retrieving of such values to/from memory other than preventing the events that fire the memory interaction.

As a last resort, I wonder if we should get away from closing the form using the methods you've listed above. I tested just hiding the form and the only downside is that the form will remain in memory until Access is closed (about 300 k for my form). In the Exit button's click event:

     Me.Visible = False

If you go this route, please remove the WM Player Enabled = False code from the Exit button's click event, or the next time users run the form within the same Access instance the form will be disabled.
     

Had the same problem.

on the onclose event of your form put:    
Me!WindowsMediaPlayer0.Object.Controls.Stop