Plugins: JPS SDK 1.02 Download (Plugin & Host examples)

[loadman]

uughh ...... I just spent an hour trying to figure what the heck was crashing my application and finally figured out it was your new plugin code      again 
Starting your new VB6Host/Project1.vbp makes it come up fine although when I click the "X" button on the top/right of the window to exit the application, then VB crashes.
How about creating a new version 
off to bed ...... 

How about you go jump in the lake? 

    I'm sure UncleT didn't mean top be rude.  Probably just tired  

As always guys love your efforts!!! 

Should I be worried about this HeadKaze? (see attached pic) 

[headkaze]

uughh ...... I just spent an hour trying to figure what the heck was crashing my application and finally figured out it was your new plugin code      again 
Starting your new VB6Host/Project1.vbp makes it come up fine although when I click the "X" button on the top/right of the window to exit the application, then VB crashes.
How about creating a new version 
off to bed ...... 

How about you go jump in the lake? 

    I'm sure UncleT didn't mean top be rude.  Probably just tired  

As always guys love your efforts!!! 

Should I be worried about this HeadKaze? (see attached pic) 

loadman: I would say that's a false positive

Well UncleT posted that when I was tired too (still am) so not the sort of thing you want to read when your tired. I dont think I should have to remind anyone that I'm doing this to help out at the request of Loadman. I have no interest in Jukebox software but the subject of plugins does interest me so I thought I'd help out. I don't think UncleT was meaning to sound ungrateful/pushy/rude so I'll just forget about it and put it down to hard work and lack of sleep.

Now the problem with the VB6 program is a mystery to me and it seem to crash randomly for me too (I knew about it when I posted and was going to wait for the cry's for help). Maybe I'm having the same problem Space Fractal had with his plugin? I tried a few different things but it still seems to crash randomly.

UncleT: Instead of bitching and moaning about my plugin code crashing your application again, how about you do a little problem solving of your own? VB6 is a ---steaming pile of meadow muffin--- language and I hate coding in it, and were using a hand full of hacks to get it loading dynamic dll's. I'm doing my best to write bug free code but I'm beginning to think it's just VB6 being the ---smurfette--- it always has been. Why do you think I left VB6 several years ago?

[unclet]

I was not trying to tick anyone off ...... sorry .... not really who I am.  I went and reread my post and I can easily see how that can be interpreted that way ..... sorry again.  Obviously just came out wrong, just trying to play around with you a bit ..... and probably just caught you at a bad time.   Just not a good idea by me    Your work is appreciated of course.

As forthe problem, I can look into the problem when I get home tonight.  This is the first time any of your plugin code has crashed for me.  I believe it is a result of something corrupting memory which occurs during ShutDown.   Have you changed anything between this v1.0 update in the "main" routines (Initialize, ShutDown and Command routines)?  I do not use any of the other routines so I know the problem lies within these three.



(EDIT)
I just looked at verified nothing changed in those three routines since your last release of them.   This crash must be a hidden bug which has existed for a while now.   

[headkaze]

(EDIT)
I just looked at verified nothing changed in those three routines since your last release of them.   This crash must be a hidden bug which has existed for a while now.   

The crash is most definately caused by NEW code added in Version 1.0 ie. The Timer code that is calling the plugin every 200 milliseconds. It's all new stuff so it's this new code that is causing the crashing, that much I know.

What I do in the plugin now is add a thread which continually reads key input. When it detects a keypress it is returned when PLUGIN_EVENT_GET is called in the Timer. Now in the Form_Unload() routine I turn off the Timer then I call the Plugin_Shutdown function of the plugin. The thread that reads input is then killed.

Code: [Select]

Private Sub Form_Unload(Cancel As Integer)
    Timer1.Enabled = False
   
    If (Not PluginArray) = True Then
        Exit Sub
    End If
   
    Dim I As Integer
   
    For I = 0 To UBound(PluginArray, 1) - 1
        Dim RetVal As Long
        RetVal = PluginArray(I).Shutdown
    Next
End Sub

Code: [Select]

Private Sub Timer1_Timer()
    If (Not PluginArray) = True Then
        Exit Sub
    End If
   
    Dim I As Integer
   
    For I = 0 To UBound(PluginArray, 1) - 1
        Dim RetVal() As String
        RetVal = PluginArray(I).PluginEventGet()
       
        If UBound(RetVal, 1) + 1 = 2 Then
            Select Case RetVal(0)
                Case "PLUGIN_EVENT_KEYDOWN"
                    Text1.Text = Text1.Text & "PLUGIN_EVENT_KEYDOWN:" & RetVal(1) & vbNewLine
                    Text1.SelStart = Len(Text1.Text)
            End Select
        End If
    Next
End Sub
I tried a couple of things thinking first "maybe the thread isn't getting enough time to close?". So first I tried adding WaitForSingleObject().

Code: [Select]

JUKEPLUGIN_API int __stdcall Juke_Shutdown(int Value)
{
// MessageBox(NULL, NULL, "Juke_Shutdown", MB_OK);

if(hThread != NULL)
CloseHandle(hThread);

WaitForSingleObject(hThread, 100);

return 1;
}
I thought that fixed it but it didn't. It still randomly crashed. Right now I'm too tired to even think about it, so I might have another look tomorrow. Your welcome to help narrow down the issue. I have a feeling removing the FreeLibrary() call might solve it like it did with Space Fractal's plugin. So maybe he was right in blaming VB6 for the issue? Or maybe having all this code in the Form_Unload() function is a bad idea. What happens when we have the shutdown and Timer.Enabled = false in a button before closing the form?

EDIT: Okay did a couple of quick tests removing FreeLibrary() and that does seem to stop it from crashing on exit 

[unclet]

The only code I am using of yours is the "DynamicDLL module file" and the "JukePlugin class module" file...... and I am only interacting with the following routines within your JukePluin class module file:

1) Initialze()
2) Configure()  <-- I have logic in my code to call this routine, but it is not being called during this crash
3) Shutdown()
4) Command()
5) routines to "get" plugin name, author, version and description

What this means is that I did not use any of the routines in the "Project1.vbp" project located in the "Form1" logic at all and I am not calling any of the individual event routines you have defined in the "JukePlugin class module"  When I want to send a command, I simply call the "Command" routine directly.    Anyway, in my code, it still crashes when y application exits, so it must be related to either Initialize, Shutdown or Commands routines somehow.  I am not even using a 200ms timer in my code to get information from the plugin either, so I really doubt it has anything to do with a Timer stuff.

I also verified the Initialize(), Shutdown() and Command() routines from the "JukePlugin class module" v10b14 matched exactly with the latest "JukePlugin class module" v1.0 ...... so this is why I believe this problem existed earlier than v1.0   Basically, it seems the code I am "currently" using from your "JukePlugin class module" v1.0 release is the same code I tested with successfully from your v10b14 release.


I then decided to play around with your "Project1.vbp" project:

I tried to comment out the "FreeLibrary hDll" line in the ShutDown routine but that did not solve the problem ... it still crashed.   I tried commenting out the call to CallFuncPtr in the ShutDown routine and it still crashed.

Here is the weird part ........ I commented out every line of the Shutdown routine and the crash stopped.   I then uncommented selected lines of the ShutDown routine back in one at a time and tested whether it crashed each time and it never did crash any more.  I got to the point of "uncommenting" all lines within the ShutDown routine and the crash can not be reproduced anymore.   This just means the routine is now overwriting memory somewhere else and it is just not crashing the "Project1.vbp" code anymore.   Bad thing is, I can not reproduce the problem either using "Project1.vbp".

** I am at work now and can not do anything until later tonight ...... 

[Space Fractal]

SoundEvent plugin updated to v1.0 Api....



The version in the plugin still set at b14 under getinfo(), which is fixed.

PLEASE NOTE: SMALL BUGS IS FIXED.

(4) CRASH BUG WHEN LOADING "MOVIE" WHEN SENT BACK.
(3) PLAY BUTTON DIDDENT WORK.
(2) GETINFO() SENT BACK A WRONG INFO.

[headkaze]

The only code I am using of yours is the "DynamicDLL module file" and the "JukePlugin class module" file...... and I am only interacting with the following routines within your JukePluin class module file:

1) Initialze()
2) Configure()  <-- I have logic in my code to call this routine, but it is not being called during this crash
3) Shutdown()
4) Command()
5) routines to "get" plugin name, author, version and description

What this means is that I did not use any of the routines in the "Project1.vbp" project located in the "Form1" logic at all and I am not calling any of the individual event routines you have defined in the "JukePlugin class module"  When I want to send a command, I simply call the "Command" routine directly.    Anyway, in my code, it still crashes when y application exits, so it must be related to either Initialize, Shutdown or Commands routines somehow.  I am not even using a 200ms timer in my code to get information from the plugin either, so I really doubt it has anything to do with a Timer stuff.

I also verified the Initialize(), Shutdown() and Command() routines from the "JukePlugin class module" v10b14 matched exactly with the latest "JukePlugin class module" v1.0 ...... so this is why I believe this problem existed earlier than v1.0   Basically, it seems the code I am "currently" using from your "JukePlugin class module" v1.0 release is the same code I tested with successfully from your v10b14 release.

Why the hell arn't you using the wrapper functions instead of calling Juke_Command directly? 

Makes me feel like I've been wasting my time 

The reason why the example is crashing for you is because YOU ARE RUNNING IT INSIDE THE IDE. VB6 is notorious for crashing when doing things like we are doing. Eg. Subclassing, threading or using API functions like LoadLibrary etc. One of the reasons for that is because the VB6 IDE is not thread-safe.

So the easy thing to do is RUN IT OUTSIDE THE IDE ie. By double clicking the exe. That is the only way we can do it, and that is why you keep getting my code crashing because I'm running the exe and your not. So I'm releasing code thinking it's working while for you (in understandable frustration) it keeps crashing! If you've ever tried to do any low level stuff in VB6 you soon find out that alot of stuff crashes running inside the IDE so in many ways I'm used to testing VB6 apps by running the exe. Just another reason to ditch VB6 for a better non-obsolete language

Now that your up to speed, the new example still crashes occationally when using the new Timer code. But I'll wait until you actually get to implementing that in your software.

(And here I was thinking we were on the same page) 

[unclet]

headkaze

I have not found the main crash but decided to use your old 10b14 "JukePlugin.jps" file and everything works fine.

I did find an error though.   After calling the ShutDown routine for all the plugins, I was calling the Command() routine one more time.   The CallFuncPtr() routine did not get called since you make sure the pCommand > 0 .... which is good.  The thing which causes my error was that "sArray" was being returned from the Command() function but it was uninitialized.   Now, the real problem was that I was calling Command() function after a Shutdown, but I just wanted to let you know that an error could occur if this happens still since sArray is not initialized.  I would try to do a UBound() check on the return value String() but it was error out.

As for the main crash which we can not find, how about streamlining your code a bit.  The only code I need from your JukePlugin class module are the following, since it is easier for me to simply call the Command() routine directly:

Private Type PluginInfoType
    Name As String
    Author As String
    Version As String
    Description As String
End Type


Private pDC As Long
Private hDll As Long

Private pInitialize As Long
Private pShutdown As Long
Private pGetPluginInfo As Long
Private pConfigure As Long
Private pCommand As Long

Private PluginInfo As PluginInfoType

Public Function Initialize(hDC As Long, PluginName As String) As Long
    Dim RetVal As Long
   
    pDC = hDC
    hDll = LoadLibrary(PluginName)
   
    If hDll = 0 Then
        Initialize = 0
        Exit Function
    End If
       
    pGetPluginInfo = GetProcAddress(hDll, "Juke_GetPluginInfo")
   
    If IsPlugin Then
        pInitialize = GetProcAddress(hDll, "Juke_Initialize")
        pShutdown = GetProcAddress(hDll, "Juke_Shutdown")
        pConfigure = GetProcAddress(hDll, "Juke_Configure")
        pCommand = GetProcAddress(hDll, "Juke_Command")
       
        If pGetPluginInfo <> 0 Then
            Dim sPluginInfo As String
            Dim sArray() As String
           
            sPluginInfo = PtrToVBString(CallFuncPtr(pDC, pGetPluginInfo, vbNullString))
                       
            sArray = Split(sPluginInfo, "|")
                 
            If UBound(sArray, 1) + 1 = 4 Then
                PluginInfo.Name = sArray(0)
                PluginInfo.Author = sArray(1)
                PluginInfo.Version = sArray(2)
                PluginInfo.Description = sArray(3)
            End If
        End If
       
        If pInitialize <> 0 Then
            RetVal = CallFuncPtr(pDC, pInitialize, vbNullString)
        End If
    Else
        RetVal = 0
        Shutdown
    End If
   
    Initialize = RetVal
End Function

Public Function Shutdown() As Long
    Dim RetVal As Long
       
    If pShutdown <> 0 Then
        RetVal = CallFuncPtr(pDC, pShutdown, vbNullString)
    End If
   
    If hDll <> 0 Then
        FreeLibrary hDll
    End If
   
    pGetPluginInfo = 0
    pInitialize = 0
    pShutdown = 0
    pConfigure = 0
    pCommand = 0
   
    Shutdown = RetVal
End Function

Public Function Configure(hWnd As Long) As Long
    Dim RetVal As Long
    If pConfigure <> 0 Then
        RetVal = CallFuncPtr(pDC, pConfigure, hWnd)
    End If
    Configure = RetVal
End Function

Public Function Command(Name As String, ParamArray Params() As Variant) As String()
    Dim sCommand As String
    Dim sArray() As String
    Dim sParams As String
    Dim I As Integer

    For I = 0 To UBound(Params)
        sParams = sParams & Params(I)
        If I < UBound(Params) Then
            sParams = sParams & "|"
        End If
    Next
   
    If pCommand <> 0 Then
        sCommand = PtrToVBString(CallFuncPtr(pDC, pCommand, Name, sParams))
        sArray = Split(sCommand, "|")
    End If
    Command = sArray
End Function


Public Property Get IsPlugin() As Boolean
    IsPlugin = (pGetPluginInfo <> 0)
End Property

Public Property Get Name() As String
   Name = PluginInfo.Name
End Property

Public Property Get Author() As String
   Author = PluginInfo.Author
End Property

Public Property Get Version() As String
   Version = PluginInfo.Version
End Property

Public Property Get Description() As String
   Description = PluginInfo.Description
End Property

Recommendations to be make easy:

1) Only include the above code in your JukePlugin class module

2) I would love it if you changed the Command() routine to take two "String" values as input instead of the second parameter being a "String()".  It is very easy to pass a formatted string to the Command() routine so this can reduce the effort applied in this command.   

3) It would be nice to have a return value of type "String" instead of "String()" from the Command() routine as well.   The return value will only have one "|" in it, so we can do our own parsing for this .....

4) I do not see why your code need to do a bunch of timer stuff you said you added, so why not just remove all of this as well.   Lets just get down to a small subset of what you have and see if this works better.  Using older versions which did not have all of this code in it (and did not pass back String() types worked a lot better.

[unclet]

I posted my last post without knowing you responded ....

I do not use your wrapper functions because it is not convenient for me.  I already had a lot of base code in place to use my own method before you started generating all this extra code so I was not going to rip all this stuff out.   Also I could not simply call "GetPluginArray()" routine and such because I have additional logic regarding enabling/disabling plugins which is not included in your code.  It is specific to my code and this type of logic surrounds the Initialize() routine call.  You use to only supply the Initialize(), Configure(), Command() and ShutDown() routines mostly which is exactly what I wanted.  I did not mention anything since I thought perhaps Barcrest was using the wrapper stuff .... sorry.   All of my command calls go through my local routine which then loops through all plugins and then simply calls Command() routine directly.

Just to let you know all of your older plugin files have worked fine for me within the IDE.  No crashes at all.  With the new version it crashes all the time.  I can not build an EXE everytime I want to simply test stuff .... that would be a pain ... I need to stay in the IDE where I can manipulate stuff quickly.  My program is too large to create an EXE everytime and debugging code would no longer be easy if I did that either.

I hope you still do my suggestions in the thread above ... probably will resolve the crash issue as well if you just remove this stuff and just create a slimmed down "JukePlugin.jps" file to use.   Remember the Juke_Command format only has two strings now separated by only one "|" character so there is no real need to keep all the "String()" logic in place.  I would much prefer to pass in "String" values and get a "String" values returned.

[headkaze]

Just to let you know all of your older plugin files have worked fine for me within the IDE.  No crashes at all.  With the new version it crashes all the time.  I can not build an EXE everytime I want to simply test stuff .... that would be a pain ... I need to stay in the IDE where I can manipulate stuff quickly.  My program is too large to create an EXE everytime and debugging code would no longer be easy if I did that either.

I hope you still do my suggestions in the thread above ... probably will resolve the crash issue as well if you just remove this stuff and just create a slimmed down "JukePlugin.jps" file to use.   Remember the Juke_Command format only has two strings now separated by only one "|" character so there is no real need to keep all the "String()" logic in place.  I would much prefer to pass in "String" values and get a "String" values returned.

It's the new plugin (JukePlugin.jps) that is crashing the IDE not the new JukePlugin.cls file. I added a thread in there to check for key presses. When people write plugins they are going to want to use threading. So just use the old JukePlugin.jps from beta 14 as that doesn't have the threading code.

This is the code causing the IDE to crash...

Code: [Select]

JUKEPLUGIN_API int __stdcall Juke_Initialize(int Value)
{
// MessageBox(NULL, NULL, "Juke_Initialize", MB_OK);

DWORD dwThreadId= NULL, dwThrdParam = 1;

hThread = CreateThread(NULL, 0, ReadInput, &dwThrdParam, 0, &dwThreadId);

if (hThread == NULL)
return 0;

return 1;
}

Code: [Select]

DWORD WINAPI ReadInput(LPVOID lpParam)
{
while(1)
{
for(int i=0; i<256; i++)
m_keys[i] = (UCHAR) (GetAsyncKeyState(i) >> 8);

Sleep(100);
}

return 1;
}
All it does is start a thread to read input to demonstrate sending data back to the plugin.

Also I don't think I'll remove those wrapper functions as they should not effect your custom functions but may be useful to other people. Personally I think they take away alot of the hastle in knowing how certain commands need to be formatted by only allowing parameters that are required. So lets just keep that code in for now.

Sorry if I've been a bit grumpy lately I havn't been sleeping well!

(the weather over here is hot hot hot)!   

[unclet]

Also I don't think I'll remove those wrapper functions as they should not effect your custom functions but may be useful to other people.

This is why I never mentioned it before .... since I thought others might fine them useful.

Anyway, no problem, I will just use the JPS file without the threading .......

[Space Fractal]

parsing commands in a thread should not been needed.

Make sure to copy the strings from the pointers got to a local string before parsing and changing it. Otherwice it might crash.

That is what I did with the SoundEvent plugin to avoid these hated memory unhandled when return back to BlitzMax. The sound player was do still needed to beeen a thread it self.

Otherwice there was no crashes in Project1.exe at all when I tested it (tried about 10-15 times), both plugins worked. So it mightbe it just a IDE problem when quit?

Even Keypresses worked as it should, the only problem it a bit slow and it diddent catch all keypresses. But I think small problem, but fine for a demo.

Please update the soundevent plugin to your SDK and remember to REMOVE soundevent.ini

EDIT: It project1.exe crashed when tried to load a MOVIE in the FileReqester in its SoundEvent config, that bug is fixed (forget to load the new sample in the thread).



 

[loadman]

Also I don't think I'll remove those wrapper functions as they should not effect your custom functions but may be useful to other people.

This is why I never mentioned it before .... since I thought others might fine them useful.

Anyway, no problem, I will just use the JPS file without the threading .......

D'oh!   I was using it for testing 

[headkaze]

parsing commands in a thread should not been needed.

Make sure to copy the strings from the pointers got to a local string before parsing and changing it. Otherwice it might crash.

That is what I did with the SoundEvent plugin to avoid these hated memory unhandled when return back to BlitzMax. The sound player was do still needed to beeen a thread it self.

Otherwice there was no crashes in Project1.exe at all when I tested it (tried about 10-15 times), both plugins worked. So it mightbe it just a IDE problem when quit?

Even Keypresses worked as it should, the only problem it a bit slow and it diddent catch all keypresses. But I think small problem, but fine for a demo.

Please update the soundevent plugin to your SDK and remember to REMOVE soundevent.ini

EDIT: It project1.exe crashed when tried to load a MOVIE in the FileReqester in its SoundEvent config, that bug is fixed (forget to load the new sample in the thread).

Who said I was parsing commands in a thread? Do you guys actually look at the code I write? lol I dont think you do!The threading was for polling the keyboard for input to demonstrate sending data back to the host app. I thought I already said that.. oh well I guess I'll repeat myself until it sinks in 

I have a buffer that I use to copy all strings into so there are no pointers to temporary memory being returned. So there should be no "hated memory unhandled" there. Check out the source I think it speaks for itself.

I removed all the threading code and turned off the timer. I think we can look at that later when everyone is ready for that. Right now it's a little troublesome although I think removing FreeLibrary solves that. As for crashing in the IDE I wouldn't even bother trying to avoid that when using threading (Again VB6 IDE is not thread-safe).

Updated source to include latest Pure Basic example

[Space Fractal]

ok. I might misforstod it, sorry.

I do not need threading for polling keyinputs (because BlitzMax dosent support threads at all), since I just do that in each Screen Update (flip()), which is set to 30FPS (in Jukebox GUI can been set at 60FPS). MultiJuke works like BlitzMax games would do.

So a 200 millsecs timer (5FPS) for testing for inputs is to slow, since some of my input never sent back....

If the threads for keyinput polling was in the last SDK, it actuelly works fine here and did the job without crash. The crash I got was nothing with due with Project1.exe, but in SoundEvent, which was fixed in v1 (4).

Can you not in the beginning in the code tell if it run in a IDE or not, so FreeLibrary does not use under codning, if it crash the IDE (but also works fine without IDE)?

[loadman]

So lets just keep that code in for now.

(the weather over here is hot hot hot)!   

Just make sure that India don't win the Cricket 

[unclet]

So lets just keep that code in for now.

loadman
Just thought I would mention that my software still does not use the threading stuff.   I believe headkaze kept that logic in his code (available in this thread) but I am not using that logic in my software.

[loadman]

So lets just keep that code in for now.

loadman
Just thought I would mention that my software still does not use the threading stuff.   I believe headkaze kept that logic in his code (available in this thread) but I am not using that logic in my software.

Do you forsee any issues?

[unclet]

No issues for me .... I just read a previous post from you in this thread indicating ...

D'oh!   I was using it for testing

.... and was not sure if you wanted thread logic embedded in the jukebox software.  Anyway, I just thought I would mention that the threading stuff headkaze put in the plugin logic was crashing my application since I use the IDE for development, so I decided not to use that piece.

Again ... no problem for me..... just wanted to mention that the threading stuff was not in there in case it matter to you ... for some reason 

[Space Fractal]

I also not not threading at all in MultiJuke (no support for that in BlitzMax), some of my Pure Basic plugins might use threading through when I release them (I guess I release a new one tommorow, a Remote Event plugin).

I guess he did a test how it would works with the keyevent functions works and can been used. Not to been used in a real API.

[loadman]

Yeah, But it cool to use the Host example in the API for testing... :-)

[headkaze]

I've removed the threading from the latest download so there should be no problem for testing. The only trouble is if you decide to use threading in your plugin then you will need to test the plugin outside the VB6 IDE.

I don't know about you loadman but I use threading alot in my LED/LCD/Speech/Sample based plugins.

EDIT: Okay updated to 1.02 and now includes a rtf (Rich Text Format) version of the readme so it's easier to read. Loadman (or anyone) if you want you can upload this to jukeplugsys.com

[headkaze]

I noticed the SDK is still not on the website?  Space Fractal can you upload the archive?

[Space Fractal]

Please register a new user on the site, and I set you as a EDITOR status  .

That SDK is your work.

I have uploaded the file now.

[loadman]

I noticed the SDK is still not on the website?  Space Fractal can you upload the archive?

Sorry   

[Space Fractal]

hehe, Loadman could also upload the file, since I gave him editor status.

If you want, headKaze, I give that one to you also, so you can update thet SDK page for new releases.