Any way to easily include repetitive Declare Function declarations?

Just checking if Xojo ever implemented a directive to include text from a separate document? I have #if DebugBuild / #else external DLL method Declare Functions that would be most convenient to declare ONCE (in CODE – not in the IDE) and then not have to declare locally in each and every method.

If not, it’s just a lot of cutting and pasting, but centralizing those definitions is a time saver.

NOTE: I can’t do it via the IDE because of the difference between DebugBuild and not DebugBuild, and because of a known Xojo bug that doesn’t permit fully-qualified paths in constants like #App.kMyDLLPath.

No, there is no include functionality, but I’m having trouble understanding your use case here. Can you say more?

Why don’t you just put a wrapper function around your declare and make that available in a public global module? This elminates the need to use the declare in more than one place.

As an example, suppose I need the Win32 function GetProcessID in two different functions.

I could do this:

Sub Foobar1
  #if TargetWin32
    Declare Function GetCurrentProcessId lib kLibKernel32 () As Uint32
    return GetCurrentProcessID()
  #endif
end sub

Sub Foobar2
  #if TargetWin32
    Declare Function GetCurrentProcessId lib kLibKernel32 () As Uint32
    return GetCurrentProcessID()
  #endif
end sub

But then if there’s a change in the Declare, I have to change it in two places.

Instead, just abstract the declare into a Xojo function so it’s in one place:

Public Function GetCurrentProcessId() as Uint32
  #if TargetWin32
    Declare Function GetCurrentProcessId lib kLibKernel32 () As Uint32
    return GetCurrentProcessID()
  #endif
End Function

Sub Foobar1
   dim id as integer = GetCurrentProcessIDW32()
end sub

Sub Foobar2
   dim id as integer = GetCurrentProcessIDW32()
end sub

Now, the declare is only in a single spot.

Also: Not sure what platform you are using, but I have an app which uses an external DLL, and it works great in debug and non-debug modes, because I’m using a Build Automation script with the copy files step.

  • On macOS you copy into the Framework folder
  • on windows copy to the App parent folder [for 64 bit windows. For 32 bit windows, copy to the Framework folder which ends up in the “MyApp Libs” folder]

No need to do any tweaking of paths depending on debug vs. non debug build.

Edit: screenshots:

image

Using it in code is then very simple:

#if TargetWin32
  const DLL = "MySpecialDLL.dll"
  declare function MyDLL_Foobar lib DLL (x as integer) as String
  dim result as string = MyDLL_Foobar(42)
#endif

The public function wrappers is a very cool way to handle that issue! It also allows for any Xojo-to-DLL-and-back glue code, like for CString to Text conversion. I will try this!

1 Like

Exactly!

See my edits above - I can give you tips for macOS dylib usage too.

So this utility I’m writing, which connects to a Windows DLL with a C-API (that I compiled in C++), is only running on Windows. The code that builds the DLL is multiplatform, but that shouldn’t matter.

I have TRIED placing the DLL in the App’s named Lib folder (ie myApp Libs), but that DID NOT WORK for both debug and .exe builds.

My builds are exclusively 64-bit on Windows. AND, if I decide to use Xojo on Mac, it will also be 64-bit only.

[Edit] If you look at your 64 bit app you’ll see there are DLLs in both locations, but in 64 bit apps, DLLs you use for Declares have to go in the root folder - they won’t work in the Libs folder for some reason. Maybe that’s it?

they won’t work in the Libs folder for some reason. Maybe that’s it?

Could be. Xojo Support didn’t clarify that, and I’m not sure if the documentation is clear on those points. I’ll experiment with all those approaches shortly.

Thanks for the expert advice!

1 Like

I’ve emailed Xojo with a documentation suggestion as well.

@Mike_D

If you look at your 64 bit app you’ll see there are DLLs in both locations, but in 64 bit apps, DLLs you use for Declares have to go in the root folder - they won’t work in the Libs folder for some reason.

This does NOT appear to be the case: is the “root folder” where the .exe is place for a BUILD? If so, that works for the .exe execution, but NOT for the DEBUG (RUN) execution.

Debug has its own “root” folder. The debug executable is built in a subfolder. Use a Copy build step to copy the DLLs into that new root folder.

+1 use the Copy File build step, in my experience it works for debug and regular builds.

@Mike_D

This seems ideal. Just to be perfectly clear: Do you then add that Public Function as a global METHOD to a Module? Or as another type? If a “method”, then are the properties (Method name, parameters, return type, scope) ALSO defined in addition to the Public Function declaration?

Is there any way to put ALL the Public Function definitions together in one single object/page? Or does each Public Function need to go into a separate item?

As a global method (or function) in a Module. In some of my projects, I have a “Globals” module which contains useful methods and functions.

In a more complex projects, I find myself separating them out by kind, e.g. W32: a module containing all my Win32 Declares. Stats: a module containing statistical functions, etc.

There are some public ones, for example WFS - if you want to see a very large example:

1 Like

It would be a global Method in a Module. You break up the human readable function definition into the properties of the method in the IDE. Eg.,

Public Function GetCurrentProcessId() as Uint32
  #if TargetWin32
    Declare Function GetCurrentProcessId lib kLibKernel32 () As Uint32
    return GetCurrentProcessID()
  #endif
End Function

becomes
Name: GetCurrentProcessId
Parameters:
Return: UInt32
Scope: Public (Global may be better)

The line Public Function GetCurrentProcessId() as Uint32 appears nowhere in code.

And yes, create a separate method for each declare.

1 Like

OK, I get it now. Of course, it would be so nice if there was at least ONE “free-form” method to add the code of multiple functions as you posted it above.

But I guess if I adhere to the Xojo religion, then “This is The Way”

Thanks for everyone’s insights. The Build Step was quite helpful, too!