Make sure the copy files step is actually in the Mac target and that it’s set for both release and debug.
it is - and the Mac target is checked as well.
This is the GUI version:
And this is the CLI version:
Oh, did you look in the Frameworks folder?
It doesn’t matter - even if I choose App Parent Folder or any of the others, no .debug folder is created in the project folder like it is with the CLI version.
Sounds like you’re doing some gymnastics to work around an issue in the wrong way. You shouldn’t need to know where the .debug build is to use a bundled dylib’s functions.
Additionally, yes, it does change depending on the target. Tell us, why do you need to know where the debug folder is?
Because that’s where the copy operation puts the files.
A) I am not seeing the Debug folder
B) I am getting a function not found error
Therefore, B seems very likely to be a result of A
CopyFiles puts it into the folder your specify, you shouldn’t need to know where on disk that is. Windows, Mac, Linux, Desktop, and Console all build the debug folder differently.
On Desktop macOS, it’s not a folder. It’s Myapp.debug.app
Here is the Command line app’s folder before I run the build:
And then I run the build:
The “grab-test-cli.debug Libs” folder is where the libraries are copied to.
the “Contents Folder” is where the ConfigTest.js folder goes.
But for the GUI version, no .debug folder is made in the first place, so there’s nowhere to put the files. And no errors are thrown.
I don’t know what more to say. I even already told you what to expect for Mac Desktop.
Update: I should add that it’s complicated to pack a console helper app into a macOS desktop app and have it share resources.
CopyFiles puts it into the folder your specify, you shouldn’t need to know where on disk that is.
Ok, I get that now. No need to tell me I don’t need to know where it is though - I’m getting an error that the function isn’t found. Therefore the first, most logical step in testing that is to make sure the library file is there. I didn’t know it was put inside the package, since I usually make command line apps, where it goes in a folder.
I don’t know what more to say. I even already told you what to expect for Mac Desktop.
Those posts were crossed. we posted at basically the same time. I read your other thread the other day and I have to say if you want people to treat you with respect for the information you offer up, you might want to try doing the same for them. Seriously, there’s no need to be the arrogant programmer dude here.
Update: I should add that it’s complicated to pack a console helper app into a macOS desktop app and have it share resources.
I’m not doing that. Not sure where that came from.
I built a CLI to test a library. Once tested I built a GUI against the same library. Different applications, as I said in my first post.
You should circle back to that thread where you dismissed the dylib pathing issue. That’s your real problem, it needs to be packed for an application bundle and I’d bet it’s not.
What thread is that, and what did I dismiss? do you mean this one? because in that case, the issue turned out not to be the path to the dylib (which was correct, and was tested as suggested using a simple helloworld library), but a configuration problem with the install of the underlying frame grabber drivers. Once that config issue was fixed, everything worked. Or are you talking about something else?
Actually, specifically this one: Help calling a function from dylib - #11 by Perry_Paolantonio
If you need further detail we can draft up a consulting contract, the research behind the answer to this took me a significant amount of time. You could also try to get Xojo to help you as part of the technical support service that’s included with your license.
Just out of curiosity, could you show the Declare code that you are using to access the library?
Is this that?
Declare Function GetBoardCount Lib "libCoaxLinkGrabber.dylib" (byref count as UInt32) as Integer
dim success, count as UInt32
success = GetBoardCount(count)
breakJust for clarity, it’s a bundle; some may say it’s a kind of folder.
Perhaps you just got a wrong feeling?
I don’t recall Tim having been as you describe…
1 Like
Tim - This is not a matter of me “dismissing” anything. I said right after that, in that same post, that the change the programmer who made the dylib made was fine. This is an application that will live on one machine, ever. It’s not being sold commercially, so I just need it to work, I don’t need a solution that will work for installations on other machines.
It doesn’t even need to be a function that has any parameters:
Declare Function OpenCxpDriver Lib “libCoaxLinkGrabber.dylib” () as Integer
dim driverOpen as integer = OpenCxpDriver()
…fails with “function not found” when called from the GUI app, but the exact same code works from the CLI app. Both are pointing to the same dylib file in the build copy operation, and both are correctly copying the file to the expected locations (inside the app package for the gui, and inside the ,debug folder for the CLI.
That’s totally irrelevant to why it’s not working.
You need to stop acting like you’re not doing anything wrong, your code is not working. I am not being arrogant, I am pointing out where your shortcuts have failed you.
I’ve told you plenty about what the problem is. Threw the terms into Google, and you may find an article that will help. By making this into a personal attack, I rescind my offer to help privately. Good luck with your research.
I did not know that the underlying frame grabber drivers were adding environment variables on install. Digging around, I saw that these were in my .zshrc file, which is why the Console app worked, but the GUI didn’t. Setting these environment variables in the Open event handler fixed it and we’re back in business.
1 Like