Problem with DLL's

[nci]

I wrote a small DLL in PureBasic and called it in Visual Basic.
The DLL Procedure opens the PathRequester. The Requester Opens
but the text that was passed is all garbled up. Possibly because of String
format differences. Does anyone know how to correct this?

Also after the Requester is closed the program crashes.
Thanks

[nci]

OK, narrowed down the problem. If any one here is familiar with VB
when I declare a procedure as a type (say String) It will crash when
the PB DLL tries to send info back to VB.

PB Code:

Code: Select all

ProcedureDLL.s DialogPath(Title.s,DefaultPath.s)
  Result.s= PathRequester(Title,DefaultPath)
  ProcedureReturn Result
EndProcedure

VB Code:

Code: Select all

Declare Function DialogPath Lib "Engine.dll" (ByVal Title As String, ByVal DefaultPath As String) As String

When using "ProcedureReturn Result" or "ProcedureReturn Result.s"
VB will crash.

If I use:

Code: Select all

Declare Function DialogPath Lib "Engine.dll" (ByVal Title As String, ByVal DefaultPath As String) As long

It doesn't crash, but returns some numbers.

If I use:

Code: Select all

Declare Function DialogPath Lib "Engine.dll" (ByVal Title As String, ByVal DefaultPath As String) As Variant

VB just says "Bad DLL Calling Convention"[/code]


What is going on?
Please help me!

Thanks

[Pupil]

PB Code:

Code: Select all

ProcedureDLL.s DialogPath(Title.s,DefaultPath.s)
  Result.s= PathRequester(Title,DefaultPath)
  ProcedureReturn Result
EndProcedure

Remember that variables inside a procedure is local to the procedure i.e. they're put on the stack, so when the procedure exits all local variables is destroyed. In your code above that means that the variable Result is destroyed when the procedure exits and VB will try to read data where it isn't allowed to, that's why it crashes.
Change your dll code to something like this and it should work..i hope

Code: Select all

ProcedureDLL.s DialogPath(Title.s,DefaultPath.s)
  Shared PathResult.s
  PathResult= PathRequester(Title,DefaultPath)
  ProcedureReturn PathResult
EndProcedure

There is an ongoing thread about this issue that might be a good read:
viewtopic.php?t=7065

[RJP Computing]

I worked up a quick example for you. I think you need to also pass the result address back not just the string. Here you go.

Code: Select all

Global FileName.s

ProcedureDLL BrowseForFolder(Title$, InitialPath$)
  FileName = PathRequester(Title$, InitialPath$)
  ProcedureReturn @FileName.s
EndProcedure

Then use this to test it.

Code: Select all

If OpenLibrary(0, "PureBasic.dll")
   path=CallFunction(0, "BrowseForFolder", "This is the area to add a title","V:\Electronics\TDE\People\Pusztai")  
    Debug PeekS(path)
  EndIf

Hope this helps.

[Kale]

One little remark i will make about this is, i'm pretty sure Fred has said somewhere that he does not like people to simply 'wrap' PB commands for use for other languages. Can any one comfirm this? I think this is one rule that is against the PB User License!

[Karbon]

Yes, though I think he's fine unless he starts distro'ing it with VB or something! It's in the FAQ at purebasic.com :

Is it allowed to use DLLs made with PureBasic in other projects ?

Generally yes. You can make DLLs including PureBasic commands for your own projects without any restrictions. But it's not allowed to release simple "wrapper" Dlls to include PureBasic commands in other programming languages.

Just out of pure curiosity, doesn't VB offer something like the pathrequester native? It's been more than a few years since I played in VB so I don't remember.

[RJP Computing]

I was giving an answer to a question. I am not just wrapping. I do think that a DLL can have the pathrequester in it. Along with other things.

[Karbon]

@RJP: I think Kale was talking about nci, not you

He said he was writing a DLL for use with VB so I'm sure that's what sparked the comment. Either way the FAQ says that it's just not to be used to extend other programming languages. I read that to mean that someone like Mark over @ Blitz can't just write one big DLL from PB wrapping every available procedure in ProdedureDLL's and pass it off as part of Blitz+

Of course I could be wrong!

[RJP Computing]

I know this is a foggy area. I am sure that Fred is very open and that is about the extent of the meaning of that statement. It just seems like when anybody talks about making a DLL this comes up. (VERY broad generalization) I just want people to feel free to ask questions first and then decide if what they are doing is ethical.

[Kale]

I just want people to feel free to ask questions first and then decide if what they are doing is ethical.

Me too

[nci]

One little remark i will make about this is, i'm pretty sure Fred has said somewhere that he does not like people to simply 'wrap' PB commands for use for other languages. Can any one comfirm this? I think this is one rule that is against the PB User License!

I'm not just "Wrapping" commands, I was planning on writing my entire
project in PureBasic, But decided I couldn't do it. (Due to PB's lack of
certain events) So I decided to write a DLL in pure basic and have it
do most of the stuff and just use Visual Basic for the GUI.

Any way, I figured it out. I realized that the numbers that were being passed
were actually memmory addresses. I just converted the address to strings
and it works fine. I will try using shared variables also.

Thanks for your help guys.

[Flype]

Due to PB's lack of certain events

What do you mean ? Purebasic if flexible enough to assume that !
Have a look at this piece of code (window callback i use in my prog) :

Code: Select all

Procedure APP_CBWindow( hWnd.l, Message.l, wParam.l, lParam.l )

  Result.l = #PB_ProcessPureBasicEvents
  
  Select Message
  
    Case #WM_ACTIVATE          :  ActivateGadget( #idInput )
    Case #WM_MBUTTONDOWN       :  APP_Hide()
    Case #WM_LBUTTONDOWN       :  APP_Drag()
    Case #WM_WINDOWPOSCHANGED  :  APP_Move()
    Case #WM_SIZE              :  APP_Size()
    Case #WM_ERASEBKGND        :  APP_Size()
    Case #WM_CONTEXTMENU       :  APP_Menu()
    Case #WM_CLOSE             :  APP_Exit()
    Case #WM_COMMAND
    
      Select LoWord( wParam )
        Case #idSave           :  APP_Save()
        Case #idEdit           :  APP_Edit()
        Case #idGo             :  APP_Go()
        Case #idWWW            :  APP_WWW()
        Case #idHidden         :  APP_Hide()
        Case #idAbout          :  APP_About()
        Case #idTopMost        :  APP_TopMost()
        Case #idExit           :  APP_Exit()
        Case #idSizeable       :  APP_Sizeable()
      EndSelect
    
    Case $30D6 ; systray event
    
      Select LoWord( lParam )
        Case #WM_LBUTTONDBLCLK :  APP_Hide()
        Case #WM_RBUTTONDOWN   :  APP_Menu()
      EndSelect
      
  EndSelect
  
  ProcedureReturn Result 

EndProcedure

through callbacks you can do every things (even in gagdets) you need i think, no ?

[nci]

What about MouseMove and MouseDown and MouseUp on gadgets?
I tried using API to get the position of the mouse and see if it's over the
gadget and it works, to a certain extent. But my complex skin interface
can't be written in PureBasic unless there is another way.

[Kale]

look at the 'AdvancedGadgetEvents(#switch)' command also i agree with Flype, all events can be captured with a callback if regular commands don't suffice.