Distributing XLSM workbooks is a way to provide add-ins to users that don't have rights to install exe's or register COM addins. But, the problem with "Selling/Distributing" XLSM workbooks is that protections are weak, and users can easily steal your source code.
> Products like [Unviewable+](http://www.spreadsheet1.com/unviewable-vba-project-app-for-excel.html) are marketed at VBA Developers that want to distribute/sell Excel Workbooks and protect the VBA <u>in a way that keeps the module content *unviewable*, even if the project is unprotected using other techniques.</u>. Depending upon the implementation and settings, the modules are viewable in Project Explorer, but the modules don't display properly in VBE.
> MVP's are using these protections on their commercial products, and ideally they'll find a use for RubberDuck too. So fixing this issue is important because it gets RubberDuck working for MVP's.
@Rossco issue #1185 (link above) has the download link to a bunch of them. I think there are a number of different "protections" that they offer, each offering various "features" (and, no doubt, various prices), so I guess each sample workbook has an example of each type.
I've had a doubt about something.
Let's say I have 4 variables, A1, A2, B1, B2.
If A1 > 0 or B1 > 0, I have to check if A2/B2 is also > 0.
What I have is the following but I'm finding it a bit redundant.
IF A1 > 0 THEN
IF A2 <= 0 THEN
DISPLAY ERROR
END IF
END IF
IF B1 > 0 THE...
how about we split up the rubberduck parser into separate classes, make everything synchronous and create a new interface that represents the entry point into the parsing/compilation functionality? that entry point could provide async facilities, but for the entire parsing
we could make the parser state immutable, create one state per module then aggregate it into one project wide state that is also immutable
testing would be easier as soon as that stuff is split up plus we might even introduce an in memory event bus for communication so that the parsing stuff is further decoupled from the GUI
I like it. I won't be able to work on my fork until much later tonight. When I get the MT stuff out (and the tests working again) I'll merge into next so we get the COM reflection stuff, and then next will be ready to accept a new parsing strategy
[retailcoder/Rubberduck]retailcoder pushed commit dad51b42 to TypeInfo: call stack issues are causing the post-resolve "Ready" state to be overridden by the "Parsed" state that triggers the resolver.
Yeah the tests pass.. but the parsed state triggers the resolving; that call doesn't return until state is set to ready, but then state goes back to parsed despite actual state being ready
Just ran your typeinfo branch code and it seems fine/fast even though it's all synchronous. Fine by me for a PR, altough some middle man running the whole thing asynchronous so the UI doesn't block at all might be a good thing to add...
I wouldn't make everything multi threaded like before, that seems to be too much for what we need...
> The Ribbon XML allows developers to name their own callback functions, so there's no way to know, from the VBE, which procedures might be called by a Ribbon CustomUI control.
In order to identify the callback names, we'll have to inspect the CustomUI XML, and while that can't be inspected from the object model, it can be found by unzipping the host document, finding the path of the CustomUI files, and then parsing the XML.
I suspect that the best approach is going to be using the OpenXML
> It seems that Unviewable+ offers configurable levels/features of protection. Presumably most instances would include the use of a Protected Project (so Rubberduck *should* handle those without any trouble), so the only problematic projects are those that *aren't* protected projects, but *do* have *unviewable* module "protection".
We should be maybe treat those special case projects as a known issue for now.
> Rubberduck's intended behavior when *any* module can't be parsed, is to skip identifier reference resolution and report a parsing error; this leaves refactorings and inspections disabled, by design.
I think we should be able to tell an *actual* parsing error from a `COMException` thrown accessing a module's code, and pretty much ignore the throwing project.
I've had a doubt about something.
Let's say I have 4 variables, A1, A2, B1, B2.
If A1 > 0 or B1 > 0, I have to check if A2/B2 is also > 0.
What I have is the following but I'm finding it a bit redundant.
IF A1 > 0 THEN
IF A2 <= 0 THEN
DISPLAY ERROR
END IF
END IF
IF B1 > 0 THE...
VBA Rubberducking
VBA Rubberducking