Zload dll?

[mdown]

Is there an OLE DLL i can call from my windows code that would allow me to provide a very simple way to download zbasic binaries to my customers?
Zload is to difficult for end users to work with.

Thanks,

-Mike

[dkinzer]

Not yet. What language is your Windows app written in?

[DH*]

Is there an OLE DLL i can call from my windows code that would allow me to provide a very simple way to download zbasic binaries to my customers? Zload is to difficult for end users to work with.

I've been asking for either a DLL or a standalone GUI app but, so far, to no avail.

In the meantime, if your main problem is with users who don't understand zload command lines you might be able to shell to zload and eliminate the need for them to deal with it. They'll still see the ugly console app, though.

[mdown]

For this app it would be VB6 for simplicity.

I just need somthing i can send my end users that works quick and easy without having to send the zbasic gui.

-Mike

[stevech]

I'd volunteer to write and contribute such a utility- similar to BLIPS that I have done for re-flashing AVRs. But I'd need the protocol specs and/or source to zload.

[dkinzer]

Can VB6 provide a callback routine? It seems to me that I read somewhere something about using AddressOf to do so. I'm thinking of an API that would supply a callback for progress updates. That way, the calling application can represent the progress in any suitable fashion.

The API might be something like the following (described in VB syntax):

Code: Select all

Public Declare Function ZXDownload Lib "zxutil.dll" (
    ByVal lpFileName As String,
    ByVal wPort as Integer,
    ByVal lpProgress as Long,
    ByVal dwData as Long) as Integer

The value returned by the API would be a success indication or error status code. The callback would be coded something like:

Code: Select all

Public Function UpdateDownloadProgress(
    ByVal wPercentComplete as Integer,
    ByVal dwData) As Integer
' add code to update the progress indicator here
End Function

The value returned by the callback indicates whether to continue the download or abort.

[DH*]

Can VB6 provide a callback routine?

Please don't do it that way. VB4-32, which I use, cannot handle callbacks.

I prefer passing the handle of a window to which the DLL can pass back messages as I've suggested previously. If you're going to use a callback, let me know now so I can quit wasting time, effort and money on a dead-end.

[mdown]

I'm not sure about the AddressOf operator, but if you called ZXDownload asynchronously and then looped the call to UpdateDownloadProgress if could be done that way.

Although an OLE interface with events would be nice...

-Mike

[dkinzer]

Please don't do it that way. VB4-32, which I use, cannot handle callbacks. I prefer passing the handle of a window to which the DLL can pass back messages[...]

There will be an alternate API that utilizes a window handle instead of a the more general solution of using a callback.

Although an OLE interface with events would be nice...

I'll make a standard DLL and you can put an OLE wrapper around it if you'd like.

[DH*]

I'd volunteer to write and contribute such a utility- similar to BLIPS that I have done for re-flashing AVRs. But I'd need the protocol specs and/or source to zload.

I believe the C++ source for ZLoad is included in the ZBasic package.

[DH*]

There will be an alternate API that utilizes a window handle instead of a the more general solution of using a callback.

Actually, I think a more general solution would be a standalone GUI app similar to what NetMedia gave me. I had a Download Firmware menu item in my Windows interface. When the user clicked on the menu item, I closed the serial port, shelled to the downloader, waited for it to finish and then reopened the port. I had a delay at the beginning of my BX-24 code to allow time to reopen the port. The user then saw all of the sign-on messages. It was pretty seamless and could be used from almost any programming language.

The user had to select the file and port from the downloader app's menu but this could be done on the command line. There was an INI file item for the title bar of the app. I documented its use in my user manual. You can see a copy at http://jeffvolp.home.att.net/bx24-aht/manual.pdf.

The VB4-32 code was quite simple.

Code: Select all

Private Sub mnuBXB_Click()

   mscomm1.PortOpen = False
   WaitForProcessToEnd "BX_OEM_Downloader.exe"
   Sleep 100
   mscomm1.PortOpen = True
   
End Sub  

Public Sub WaitForProcessToEnd(cmdLine As String)
 
  Dim retVal        As Long
  Dim pID           As Long
  Dim pHandle       As Long
  
  pID = Shell(cmdLine)
  pHandle = OpenProcess(&H100000, True, pID)
  retVal = WaitForSingleObject(pHandle, -1&)
  
End Sub

[stevech]

I'd volunteer to write and contribute such a utility- similar to BLIPS that I have done for re-flashing AVRs. But I'd need the protocol specs and/or source to zload.

I believe the C++ source for ZLoad is included in the ZBasic package.

Right you are! Thankfully, it seems to be C rather than C++ or C#.
It needs to be GUI-ized.
And the VM side needs a way for the user program to trigger a download reception rather than as now, only via the tickle of the serial port DTR

[dkinzer]

I'd volunteer to write and contribute such a utility- similar to BLIPS that I have done for re-flashing AVRs. But I'd need the protocol specs and/or source to zload.

You might want to hold off for a few days. The code is being refactored to make it more modular.

[stevech]

oui messr

[DH*]

I believe the C++ source for ZLoad is included in the ZBasic package.

Right you are! Thankfully, it seems to be C rather than C++ or C#.

I misremembered that it was .cpp.

It needs to be GUI-ized.
And the VM side needs a way for the user program to trigger a download reception rather than as now, only via the tickle of the serial port DTR

That sounds great - two birds, one stone.