I use B4Xpages exclusively. There are times when my designer views are spread over multiple pages.
I am often expedient (lazy) in how I name these views (button1, label1, etc.).
The result is that I have to examine layout files in each platform for the views I am looking for.
When I find them, I have to use the search function repeatedly to see in which modules they are
used/modified/referenced (possibly with a different event name).
'WiLDocAid' does this work for me. You might find it useful too.
B4X is in many ways self-documenting, with comments showing in intellisense, searching functions, and the modules tree.
If you are more disciplined with your naming convention then I am, you probably won't need this tool.
This app depends on the standard folder/file structure of a B4X project. There are two key techniques.
1. I took half of @Erel 's code in the BalConverter app (the BalToJson part just before saving the .json file)
- this module returns a map of the views in a .bal, .bjl, or .bil file.
- WiLDocAid traverses this map and extracts information about each view recursively
2. I then examine each platform's folder .b4* file for the header information at the top showing which modules (and their paths) are used.
- the lines in the .b4* file and in all the .bas modules referenced are then searched for instances of each view found in 1.
After entering a project path in a texfield, and selection of a particular view on a CLV, the results are presented in a scrollable BBCodeView.
There is a button for copying a text-only version to the clipboard, so that you can paste it in your documentation.
Unzip and open the attached, and run. Paste the project path in the textfield or leave blank to browse. Press enter or click
Select a view from the list. That's it.
If you like it, you can turn it into a .exe to avoid having to compile it each time.
I don't need it very often, so it is not open all the time, but I do have a shortcut on my desktop.
Caveats:
1. I tested it extensively on my system, but there may be edge cases I missed. Let me know.
2. If a view in one module has the same name as a non-view variable in another, the non-view will also be documented
When I ran WiLDocAid on one of my larger projects, I discovered this. I decided to rename the non-view.
Comments are welcome.
I am often expedient (lazy) in how I name these views (button1, label1, etc.).
The result is that I have to examine layout files in each platform for the views I am looking for.
When I find them, I have to use the search function repeatedly to see in which modules they are
used/modified/referenced (possibly with a different event name).
'WiLDocAid' does this work for me. You might find it useful too.
B4X is in many ways self-documenting, with comments showing in intellisense, searching functions, and the modules tree.
If you are more disciplined with your naming convention then I am, you probably won't need this tool.
This app depends on the standard folder/file structure of a B4X project. There are two key techniques.
1. I took half of @Erel 's code in the BalConverter app (the BalToJson part just before saving the .json file)
- this module returns a map of the views in a .bal, .bjl, or .bil file.
- WiLDocAid traverses this map and extracts information about each view recursively
2. I then examine each platform's folder .b4* file for the header information at the top showing which modules (and their paths) are used.
- the lines in the .b4* file and in all the .bas modules referenced are then searched for instances of each view found in 1.
After entering a project path in a texfield, and selection of a particular view on a CLV, the results are presented in a scrollable BBCodeView.
There is a button for copying a text-only version to the clipboard, so that you can paste it in your documentation.
Unzip and open the attached, and run. Paste the project path in the textfield or leave blank to browse. Press enter or click
Select a view from the list. That's it.
If you like it, you can turn it into a .exe to avoid having to compile it each time.
I don't need it very often, so it is not open all the time, but I do have a shortcut on my desktop.
Caveats:
1. I tested it extensively on my system, but there may be edge cases I missed. Let me know.
2. If a view in one module has the same name as a non-view variable in another, the non-view will also be documented
When I ran WiLDocAid on one of my larger projects, I discovered this. I decided to rename the non-view.
Comments are welcome.
