Type/End Type vs Structure

Generally speaking, only old people year old times… since I am olmost 66 yo (programming since 1979) it might be so in my case.

I am trying to select a microphone for recording. Natively it seems that MoviePlayer plugin is a player only, not as VB whereas the MMControl is capable of recording audio.

At once the search “xojo audio recoring” show this article that, definitly works, thanks!

[Eugene Dakin] (https://forum.xojo.com/u/Eugene_Dakin)

Sound recording with API

I kind of woke up the also year times, but very much happy to find the the Xojo community helps the way VB5 and VB6 people made VB strong.

Tested, the procedure recorded from a webcam microphone, which was no the prefered device, In fact, not even changing the default device in Windows, the recording was still only from the webcam.

Therefor, I begun the search for a waveInGetDevCaps that worked for me in the good old times. Sadly a Ransomware still has my old code jailed!

After fighting a little with the syntaxis differences, I crashed my self with the definition of the Type/End Type then, structure now.

First, the Structure most be created in a kind of wizard, that is not natural, to say the least. But no char, no Long, nor Short types are named as such (or describe its equivalences in Xojo, except for Short).

at an ACTION of a cmd_list PushButton, the following code

Declare Function waveInGetNumDevs Lib "winmm.dll" Alias "waveInGetNumDevs" () As UInt16
// works perfect

  Declare Function waveInGetDevCaps Lib "winmm.dll" alias "waveInGetDevCapsA" (_ 
  byval uDeviceId As UInt16, _ 
  lpCaps As App.WAVEINCAPS, _
  ByVal uSize As UInt16) _ 
  As UInt16

  dim iJ as integer
  dim iCount as integer
  dim iNames() as string
  dim iDeviceNames as string  
  dim iWAVEINCAPS as APP.WAVEINCAPS   //where seems to be the issue is
  dim iSize as UInt16
  dim iResult as UInt16

  iCount = waveInGetNumDevs()
  lst_device_in.addrow "count: " +  str(iCount)

  for iJ=0 to iCount-1
    iResult = waveInGetDevCaps(ij, iWAVEINCAPS,68)
    for iK=0 to 31
      iLabelResult = iLabelResult + str(iWAVEINCAPS.szName(ik))

    lst_device_in.addrow _ 
      format(iResult,"0000")+ ">"  + _

sorry for my old programming style

At the APP open event, the structure is declared

in VB the structure will be declared as follows:

      wMid As Integer
      wPid As Integer
     vDriverVersion As Long
     szPname As String * MAXPNAMELEN
     dwFormats As Long
     wChannels As Integer
     dwSupport As Long
End Type

But no matter what variable type i use (Uint16, Uint32, Uint64, Integer, Int16, int32 or int64) in any possible combination, works not. Seems to be the same with the Byte (Char) array.

After recognizing the devices in the pc, I only receive zeros. And the label is empty.

Obviusly, I most understant that I am missing some things in regard to the structure and the way variables are declared in Xojo, or the array of bytes within it.

Does any one have an idea of what i am missing?

Thanks in advanced!


1 Like
  1. Are you building a 64 bit or 32 bit EXE?
  2. Here’s a comparison of your structure with the Win32 API
    WAVEINCAPS structure (Windows) | Microsoft Learn

  • the vDriverVersion field is 4 bytes (UINT64) in your Structure, but according to microsoft,

Version number of the device driver for the waveform-audio input device. The high-order byte is the major version number, and the low-order byte is the minor version number

Which suggests it’s a UINT16.

I think a similar issue is happening with dwFormats where you have it defined as 8 bytes but it should be 4???

1 Like

Also, i believe the Declare has similar issues:

byval uDeviceId As UInt16

is passing a UINT16, but the API defines this as a Pointer to a UINT16:

MMRESULT waveInGetDevCaps(
   UINT_PTR     uDeviceID,
   UINT         cbwic

So your declare should be using ByRef not ByVal

Also, from wine/mmsystem.h at master · wine-mirror/wine · GitHub I believe that MMResult is a UINT which means UINT32.

Thanks Mike
i will test the changes you suggest and will keep you updated.

Thanks again!
in regard to your first question
operating in windows 7 64
executing in computer
the build arquictecture x86 32-bits
any comment in this regard?

Decalres for 32 bit EXEs are usually easier - when doing 64 bit EXEs you have to pay attention to additional rules about which types are 64 bits vs. 32 bits and it’s not always obvious. If you build a 64 bit app (highly recommended) you would want to read The New Data Types - Win32 apps | Microsoft Learn

hello, and thanks

When x86 32-bit is selected, the RUN icon is enable

When x86 64-bit is selected, the RUN icon is disable

and is an operating systema Windows 7, 64 bits

My guess would be that you are using an old version of Xojo?

Also, I’m sure you know, but windows 7 is obsolete.

OMG when did Windows 128 get released? I missed that!


yes Mike, both are kind of old
windows 7, xojo 16r3

I don’t have fond memories of Xojo 2016, and I think the support for 64 bit Windows apps was poor. I’m quite happy with Xojo 2019R1.1, which is the last version of Xojo that is purely “API1” and has good support for x64 windows apps. I would upgrade to that version if possible, or to the latest version (2022 R3 or later).

Windows 7 has been “End of Life” since January 2020 - I think Xojo will work perfectly fine on Windows 7, but you might want to think about upgrading.

This is assuming you are writing an application for other people - if this is just for your own hobby use, it probably doesn’t matter much, and building a 32 bit app is just fine…

Yes it was. And many releases after had bugs, also the Direct2D over GDI+ saga full of bugs started too, for years. 2017 and 2018 were dead years for me.

Generally speaking, the “end of life” is kind of symbolic, mainly referred to the automatic updates… i was amaze of discovering in 2022 corporations still using XP, one of the most stables versions of Windows. Today though, there is a collusion between hardware, operating systema and software to force upgrades which is, in my opinion, more a consuming strategy, than real needs.

And agree that the programming enviroment is another world, but over time i have learned that is best if i do testing of software in “obsolete” enviroments, like windows 7, dual core processors and without the “benefits” of new versions like Windows 11. This since migration to news versions is not as fast, as i just pointed.

I do programming for clients, mainly webapps, now i have been requested a desktop app that needs to record audio. It is hard for me to understant why XOJO 2016 cannot do what VB 5 (1991( did without problem. I did later, with vb6 the same app (lost as i said with a ransomware in 2017) a was recording audio (and video) and was able to select the devices, with the exact same DLL.

In the third world, where i do mainly programing for desktop, the situation is more of “not changing your cel every year”, to say it in a manner.

That it is very likely that all (or most) the bugs from 2016r3 were over in 2019 version, which as i understant, works fine with w7.

I might to manage the desktop program with VB6, at least for detecting the list of available input devices.

Thanks for all the help!

2021r2.1 is the best of both worlds for me - I think it’s the last version before all the “DesktopXXX” stuff. Some improvements and features beyond 2019, all API1 stuff still works, you can enable autocomplete for API1 by modifying Xojo’s pList, and you can get used to API2 at your own convenience.

No need to edit plist files, there’s a setting in preferences. Coding tab, Autocomplete, Show deprecated items.

Not in 2021r2.1.

Fair enough. Anyone wanting Ventura support is going to have to be on 2022r4.1 very soon.

I only update MacOS when absolutely forced to by major incompatibilities. Every version since Snow Leopard has gotten worse in some way.

I think it also affects any application you make if you use system.version.

Which may not matter to you either.