Topic: [SOLVED] Is it safe to do GUI stuff inside a SYNCPROC callback?

[jpf]

I thought it wasn't safe to do GUI stuff inside a SYNCPROC callback, but now I see that the VB NetRadio example does it:

Code: [Select]

Sub EndSync(ByVal handle As Long, ByVal channel As Long, ByVal data As Long, ByVal user As Long)
    With frmNetRadio
        .lblName.Caption = "not playing"
        .lblBPS.Caption = ""
        .lblSong.Caption = ""
    End With
End Sub

Code: [Select]

Sub DoMeta()
'...
        frmNetRadio.lblSong.Caption = TmpNameHold
'...       
End Sub

Sub MetaSync(ByVal handle As Long, ByVal channel As Long, ByVal data As Long, ByVal user As Long)
    Call DoMeta
End Sub

Maybe it depends on the type of sync? I briefly tried this with the BASS_SYNC_END and it doesn't seem to crash the IDE.

[Chris]

It can crash but it can also not crash.
I suggest to do it via a Postmessage , to be on the secure Side.

[Ian @ un4seen]

I think it varies from platform to platform, and API to API. It may not crash on some platforms/APIs but it might still cause a deadlock. For example, if the GUI stuff internally has to run/wait on the main thread, and the main thread happens to be waiting for the sync's thread to release a lock. Setting the BASS_SYNC_THREAD flag on a sync can help avoid that (by moving the SYNCPROC to another thread), but note it isn't applicable when you need the SYNCPROC to run before BASS continues processing, eg. it'll break custom looping. In those cases, you could do the main work (eg. custom looping) in the SYNCPROC and do any GUI stuff outside it (eg. post a message for it like Chris suggests).

[jpf]

It can crash but it can also not crash.

I hope that Ian may be more specific about this.

I suggest to do it via a Postmessage , to be on the secure Side.

I was doing it via Postmessage so far, but the NetRadio example fired my curiosity. (Is there a bug in the example? Then the example is an example of what you shoudn't do!)

I think it varies from platform to platform, and API to API. It may not crash on some platforms/APIs but it might still cause a deadlock. For example, if the GUI stuff internally has to run/wait on the main thread, and the main thread happens to be waiting for the sync's thread to release a lock. Setting the BASS_SYNC_THREAD flag on a sync can help avoid that (by moving the SYNCPROC to another thread), but note it isn't applicable when you need the SYNCPROC to run before BASS continues processing, eg. it'll break custom looping. In those cases, you could do the main work (eg. custom looping) in the SYNCPROC and do any GUI stuff outside it (eg. post a message for it like Chris suggests).

Thanks, Ian! That really helps.