I’ve spent the last few days creating a small app for myself to more easily create classes which wrap apple declares. It parses HTML downloads of the apple docs for a class to create corresponding Xojo methods and properties in a class. It then uses the CodeGeneration classes to output a project file. It is by no means perfect and cannot recognize byref functions or create delegates, and class hierarchy is not preserved so you will have to fix that manually. It also skips enumerations and constants because the CodeGeneration classes do not have support for them, however it eliminates much of the tedious copying required when wrapping an apple class in Xojo. I thought that maybe it would be a help to some of you, so I figured I would share.
To use, simply download the html of the docs for a class (Option-Return in the search bar of Safari will download), drag and drop as many as you like into the green dragging area, then choose a location to save the outputted project file with all of the generated classes. From there resolve any issues when loading the file in Xojo (the bundle ID will need to be added and the target updated to Cocoa, or you can skip this and press close) and then copy the classes into the Xojo project where you need the classes.
[quote=153668:@Jason King]I’ve spent the last few days creating a small app for myself to more easily create classes which wrap apple declares. It parses HTML downloads of the apple docs for a class to create corresponding Xojo methods and properties in a class. It then uses the CodeGeneration classes to output a project file. It is by no means perfect and cannot recognize byref functions or create delegates, and class hierarchy is not preserved so you will have to fix that manually. It also skips enumerations and constants because the CodeGeneration classes do not have support for them, however it eliminates much of the tedious copying required when wrapping an apple class in Xojo. I thought that maybe it would be a help to some of you, so I figured I would share.
To use, simply download the html of the docs for a class (Option-Return in the search bar of Safari will download), drag and drop as many as you like into the green dragging area, then choose a location to save the outputted project file with all of the generated classes. From there resolve any issues when loading the file in Xojo (the bundle ID will need to be added and the target updated to Cocoa, or you can skip this and press close) and then copy the classes into the Xojo project where you need the classes.
Awesome, what I would suggest you do is to work from the .h files instead, many a times there are functions and info missing from the web docs, plus the format of a .h file
Is unlikely to change (famous last words)!
[quote=153673:@Sam Rowlands]Awesome, what I would suggest you do is to work from the .h files instead, many a times there are functions and info missing from the web docs, plus the format of a .h file
Is unlikely to change (famous last words)![/quote]
Good idea, I’ll look into this.
Hi Michel, you have found one of the fundamental flaws of using the docs instead of using the header files directly when generating the classes. The formatting between the different doc pages can vary drastically, making accounting for every single variation impossible. Looking through the HTML of the NSEvent class, I can see exactly why it fails, the formatting of the methods and properties is different than the 30 or so classes I was using as a test case. Fixing DeclareMaker to properly parse this doc file (and presumably others) would be a pretty large task. I would go through with trying to fix it but I was given a heads up the other day that someone is creating an app that parses the header files instead of the docs (I’m going to leave them unnamed for now since I’m not sure they want it known yet). Creating the classes from .h files is going to be much more reliable than using the docs.
For now since NSEvent is in MacOSLib would you be able to copy the class from there? DeclareMaker will generate a class nearly identical to what is in MacOSLib unless a delegate is involved (in which case MacOSLib will work properly and DeclareMaker may or may not work). If you come across another class which doesn’t work but is not in MacOSLib let me know and I will try to fix it to parse the docs for that class. I’m sorry for the unsatisfying answer, but with an app using a better method coming soon, and the existence of NSEvent in MacOSLib I don’t think that spending the time to fix DeclareMaker is worthwhile right now
[quote=154719:@Jason King]Hi Michel, you have found one of the fundamental flaws of using the docs instead of using the header files directly when generating the classes. The formatting between the different doc pages can vary drastically, making accounting for every single variation impossible. Looking through the HTML of the NSEvent class, I can see exactly why it fails, the formatting of the methods and properties is different than the 30 or so classes I was using as a test case. Fixing DeclareMaker to properly parse this doc file (and presumably others) would be a pretty large task. I would go through with trying to fix it but I was given a heads up the other day that someone is creating an app that parses the header files instead of the docs (I’m going to leave them unnamed for now since I’m not sure they want it known yet). Creating the classes from .h files is going to be much more reliable than using the docs.
For now since NSEvent is in MacOSLib would you be able to copy the class from there? DeclareMaker will generate a class nearly identical to what is in MacOSLib unless a delegate is involved (in which case MacOSLib will work properly and DeclareMaker may or may not work). If you come across another class which doesn’t work but is not in MacOSLib let me know and I will try to fix it to parse the docs for that class. I’m sorry for the unsatisfying answer, but with an app using a better method coming soon, and the existence of NSEvent in MacOSLib I don’t think that spending the time to fix DeclareMaker is worthwhile right now :([/quote]
So I was the classic case of the naive user hitting exactly the wrong button when asked to beta test – sorry
I understand. Already, being able to generate a class from a documentation for a majority of pages is a pretty awesome feat. I will use the class from MacOSLib.
When I pressed Option-Return in Safari, the resulting HTML could not be used by DeclareMaker. So I went into Chrome, and saved the page as HTML.
UIPrintInteractionController Class Reference.html
Then when I dropped it into DeclareMaker, it did display “UIInteractionController” in Included Classes. But when I tried to save, I got
Then when I click OK at that box, I get
And the app quits
I have done something similar with the UIPrintInteractionControllerDelegate Protocol Reference page. The Safari Option-Return saves an unusable file. Trying to save the page creates a folder with js files in there with both Safari and Chrome. What I did was to go View/Developer/View Source, copy the code into a text editor, and save that. Then I dropped it into DeclareMaker, and it very nicely processed it, then I was able to save the project.
Encouraged by that result I tried to drop UIInteractionController into it again, it did add it to the classes, but still crashes upon save. Looks as if that particular documentation contains the poison pill.
I am reporting it and posting the poisonous file to try an help debugging it.
I am glad, though, as I found a process to go around the problem with the Apple documentation inconsistencies with the Safari save. And am still impressed at the beautiful accomplishment it is to transform the Apple verbose description into an actual Xojo project.
One thing you should know is that although DeclareMaker is happy to create a class from the delegate docs, it will not function as the delegate whatsoever. To make a delegate class function it requires more work which cannot be generalized in DeclareMaker as far as I can tell. Looking at the docs for the UIPrintInteractionContollerDelegate protocol, none of the methods need to be implemented if you are doing basic printing. You only need to implement the delegate for “more advanced” printing where you want to select the paper, or if you want to disable animations in your views prior to showing the printing view.
One thing you should know is that although DeclareMaker is happy to create a class from the delegate docs, it will not function as the delegate whatsoever. To make a delegate class function it requires more work which cannot be generalized in DeclareMaker as far as I can tell. Looking at the docs for the UIPrintInteractionContollerDelegate protocol, none of the methods need to be implemented if you are doing basic printing. You only need to implement the delegate for “more advanced” printing where you want to select the paper, or if you want to disable animations in your views prior to showing the printing view.[/quote]
I really appreciate your help Jason. And the new version of DeclareMaker. I will try to get UIPrintInteractionController to print. I suspected the delegate was more complex anyway. I am already so grateful for what you have produced. It would have taken me days for what takes minutes with your program
It would be nice if I could drop plain .h onto the tool because I am trying to get declares for a 3rd party ObjC lib, which obviously does not appear as a hml apple doc file.
Also, have you considered making it open source so other could improve on it?
Sure, I’ll post the source in a couple of hours once I get back to my computer and can put it on drop box. The only reason I didn’t release the source is because it is really “horrifying” code with few to no comments that I threw together in a day and a half and have been patching whenever it stumbles on something so it would probably be difficult to understand/fix. I actually had some plans to make a more generic but less automated program/mode in a few weeks but I’ve been too busy to consider doing that yet.
Yeah, well, if someone feels that the code is horrible, leave it to them to improve it
And please do not share via Dropbox. That makes it impossible to merge changes unless everyone uses Arbed
Better upload to github or bitbucket, tag it with “xojo”, and make it public. Upload it as a vcp (xojo_project) format, not XML nor binary. Then others can clone it and make their own changes and you can later merge it easily (especially with github) if you like.
