@this Did that issue I linked, and the MSDN article it referenced, reconcile with your understanding of Access and the IDL indicator?
@Duga IIUC, we're still exporting modules to get the text, but that wouldn't be necessary if we got the text using the method described by Wayne. Does this refactor cater to parsing the text, regardless of where it comes from?
Currently creating a 'master' tasks sheet for work, that can draw uncompleted (pending or overdue) tasks from multiple worksheets (upto 10 different projects) and sort through the data. The most lines of data to be on a worksheet is probably 50 rows and 8 columns, but the worksheets grow with fol...
> The type description implicitly defines a global variable with the same name and type described by the type description. This variable is also globally accessible.
which is why it is possible to do a Cells(1, 1) inside an Access VBA project that references an Excel library - that creates a implicit Excel instance which creates all kind of problems.
@MathieuGuindon about the implicit application? Yes, it has been written about avoiding implicit references precisely because of that but about the technical details about why? IDK.
yes, VBA does a horrid job of differentiating the type libraries.
and in Access, at least, people only bother to disambiguate DAO.Recordset and ADODB.Recordset because it's an object type they use a lot and often within same project but I've rarely seen anyone else consistently use two-part naming that I insist.
I ran into a similar situation with the IOle*** interfaces. An ActiveX control must implement those but there is no way to cast MyActiveXControl into say, IOleObject without accessing the original class's method (or some equivalent operation).
The case I describe is exceptional, though. Normally, it's in COM developers' interest to provide access to other interfaces so it's no problem converting IFoo into IBar but IOleObject is of completely different concern so there's no point in converting IFoo into IOleObject (?)
BTW, I read the article that ThunderFrame linked to.... it does not say so but the behavior it describe sounds suspiciously too much like the appobject.
It might be that that the decorating of a class with Global*** has the effect of adding the appobject attribute / TFLAG_APPOBJECT flag, which causes the same behavior we observe with Excel's Global class and Access's Application. I presume Word uses Application as well....
@MathieuGuindon I wouldn't say this prevent you from having a replacement. It's more that you can only expose what the developers want you to see, no more, no less.
> Good points all around. I only have a question - is there something we can do with the PR #4153 so that it can help move toward that ideal you describe?
Yeah. Just think of it as simply another predeclared object.
rather, a special kind of predeclared object where you can skip the reference to the object's name and access members directly.
This is also why if you see a VBA project that references 4 Office products and few more, you are going to end up with lot of weird behaviors due to all those implicit references and global namespace pollution.
@MathieuGuindon I know RD fakes function declarations for LBound and UBound, and fakes declarations for the Debug class and its Assert and Print methods. Are there any other language keywords that get fake declarations, or is that it?
#DidYouKnow An implicit Excel.Application instance is created when your not-Excel VBA code is too... implicit. Good read, important stuff:
https://btabdevelopment.com/why-excel-has-a-problem-when-using-code-in-access/
> This is what the VBA Rubberduck project is all about. They should be sponsored by Microsoft as an official plugin. I would love to see it accepted and integrated.
> In a sense, yes and in a sense, no. What we could figure out in the PR is having we want to handle setting the parsing mode strategy. But maybe this will look different in the final design.
I can currently think of three ways to go for the class parsing token streams into parse trees:
1. Have one class per parsing mode strategy with the actual antlr parser getting constructor injected. 2. Having a base class implementing the three strategies in different methods and choosing based on
@ThunderFrame Yes, part of the idea of the refactoring is to completely separate getting the code from parsing it. The only thing that would need to change when switching to another method of getting the code for the attributes pass would be the corresponding source code provider.
I am working on a bit of a multiple part project, the goal of the project is to have a spreadsheet full of order data (order number, customer data, products ordered, prices etc) merged so that the duplicate information is grouped up.
https://gyazo.com/3034782c17256afac40f6a31cd469dc1
^example o...
@ThunderFrame Sorry - the article was originally written by a former MVP, Bob Larson - btabdevelopment was his site for a number of years until my company bought it. Hence the branding.
@this the chat history is full of discoveries, it's a good thing the search capability is reasonable (but not perfect), or we'd gradually forget everything. Fortunately most of the good stuff ends up in GitHub issue at some point.
I'm still confused/unconvinced by how controls expose IControl. Even if it is a hidden interface(s), we might not have a choice other than to manually add the IControl members in RD?
I need to look closer at that first to make sure I'm not talking gibberish
but AIUI, Wayne already solves the problem via the typelib API
unlike the IOle*** scenario, I believe you can cast a MSForms.TextBox to IControl, right? If so, then we can discover all interfaces by cycling all the ITypeInfo that an object has.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4153?src=pr&el=h1) Report > Merging [#4153](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4153?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/debf4a6bc809b79fa70428de598b6913b068905d?src=pr&el=desc) will **increase** coverage by `0.04%`. > The diff coverage is `85.71%`.
> Hi, I'd love to use Rubberduck, but I just can't get the parser working in a bigger project. Cheers Matthias
Version 2.2.0.3439 OS: Microsoft Windows NT 10.0.17134.0, x64 Host Product: Microsoft Office 2013 x86 Host Version: 15.0.5013.1000 Host Executable: MSACCESS.EXE
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4153?src=pr&el=h1) Report > Merging [#4153](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4153?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/debf4a6bc809b79fa70428de598b6913b068905d?src=pr&el=desc) will **increase** coverage by `0.04%`. > The diff coverage is `85.37%`.
@this isn't there a chance that the TypeLib for the project is contrived, (i.e. just like Left and Left$ are in the generated VBA TypeLib, but not in the underlying TLB, the generated TypeLib for the project might add the IControl members manually)?
I guess we'll need to observe the TypeLib and see. Now, where was that issue for building a better Object Browser...
BSTR _stdcall _B_str_Left(
[in] BSTR String,
[in] long Length);
[entry("(null)"), helpcontext(0x000f653e)]
VARIANT _stdcall _B_var_Left(
[in] VARIANT* String,
[in] long Length);
Based on that, I have to think that the aliasing is happening at higher level than TLB.
That's a completely separate thing from the issue w/ a object not exposing an interface.
In case of IControl, I just verified and yes a MSForms.Textbox can be cast to IControl, even though the coclass Textbox does not expose IControl as one of possible interface. From that observation, it has to mean that they set up the QueryInterface to allow substituting the one with the other.
@this Yep, but the VBE Object Browser is a lie. It does show the aliases, but doesn't show the underlying functions (even though they still work in code)
As I said earlier, the developers can choose whether they will tell you that their object exposes so and so interfaces or not. They are not obliged to tell you about all interfaces their object implement and there is no method within COM framework to enumerate all interfaces.
Not sure I follow the part about showing alias but not function.
@this The OB doesn't show you _B_str_Left or _B_var_Left but VBA will let you use them in code, but it does show Left and Left$ (where the $ in Left$ is not a type suffix, but is actually part of the function name) even though they don't actually exist in the TLB.
@this hence the OB is a lie, but then I suspect the TypeLib does have the aliases, even though they're not defined anywhere in the TLB.
@this I don't think so, but then VBA might choose to only alias those functions if they're in the VBA TypeLib? A 3rd party TLB might just show the underlying functions. But I agree, we should check.
Hence why we should test with a custom TLB to see if VBE will give the same treatment to the _B_str_foo
I looked quickly but I don't see any MIDL documentation suggesting that they decorate names, but that might not be MIDL's problem at all. It might be a convention held by the VBA environment, for example.
I already answered a similar question here, about periods . in a name, but I'm unsure about whether the same rule holds for backslashes.
Is it possible to write a UDF in VBA that contains a period in the name?
If the UDF is written in an external library, will the library allow backslashes in f...
@ThunderFrame a question, is there a byte somewhere to represent an alias or is this alias only recognized from a structured data perspective as in the order of which data is received to represent? in other words, how to do know that it is an Alias? on a higher level you mentioned left$ lower level is ...?
@PeterMTaylor Left$ doesn't exist in the library, but _B_str_Left does. There doesn't appear to be any byte or flag or attribute that makes VBA create the alias, so Rubberduck has always assumed that a method that starts with _B_str_ should take the remaining characters and create an alias with a $ suffix. We just don't know what the exact rules are, and which process is responsible for it in VBA.
We also don't know if there might be other things that aren't as they appear in the Object Browser.
@this Of course, the VBA library has always been special. For example, VBA will not allow you to use CLng on the LHS and ignore the result: CLng 1 'Syntax error, but prefixing it with VBA is valid: VBA.CLng 1 'Not a syntax error. However, VBA will let you use CDec in either form: CDec 1 'Not a syntax error and VBA.CDec 1 'Not a syntax error
it's almost like VBA is treating CLng as an internal keyword rather than a library method.... And whoever implemented CDec didn't read the comments...
and it might be that they are same; only that compiler treats it differently. IOW, p-code could be identical but compiler has some special if() that executes when it encounters that particular p-code(s).
One thing is for sure. VBA library and compiler were probably written by cowboys.
IMO, we do need to encourage more modularization. With vanilla IDE, the tendency is to encourage people to make one huge sized module so that they can avoid dependencies.
It's a PITA to find that to use this module, you need that module, which needs that module which ....
so I see lot of people dumping it into one module so that it's easy to export and share.
@this haven't got long, but... it is VBA that does the $ special casing for _B_str etc, and it does this regardless of what library (i.e. not just the VBA type library)
With regards to special internal functions, this is absolutely correct. VBA inlines some functions for performance reasons. For example, if you've got CInt(SomeLongValue), instead of going to the VBA library version of CInt(Variant), it can just handle the specific Long to Int case
There are many execode opcodes that handle these optimized conversions, and also LBound/UBound
Contributors are expected to know how to handle constructive criticism on their post. Questioners are expected to treat it like a personal attack and lose their marbles. — Hans Passant2 days ago
> Most of all, I would like to see a migration path from MS Access using SQL Server to VB 6. Starting with some sort of integration of MS Access into Visual Studio.
I just noticed that _B_str_Left is the actual name defined in the DLL. Yet we use Left$ in VBA. Where is the alias defined? Is this what you and Thunder were discussing?
@this haven't got long, but... it is VBA that does the $ special casing for _B_str etc, and it does this regardless of what library (i.e. not just the VBA type library)
Which kinda of stinks because that implies that if you have a type library that uses the VBA convention, the other languages that tries to use the type library are #Screwed
Granted, there's not much use for say... C# or even C++ client to use VBA type library.
So what I'm saying is that whoever wrote the type library really did not give a fig about portability. "This will be forever and more used by VBA and no others.", which kind of contradicts the whole premise of COM (which promises you that you can use any language as long you adhere to the same binary convention).
with an ABI, you are basically saying "this space here is something, and that region is something else" - everything is laid out at the binary level.
which is why COM is language-agnostic. All you need to do is to build the v-table and interfaces to the specifications it requires, with all the pointers in the right location.
so that's why you can in theory create a COM object with literally any language; it's a matter of having enough control over the binary output emitted by language's compiler.
they're almost inseparable. Heck, we're still using COM even in latest and greatest release of Windows. But the intended goal of COM was indeed to be language-agnostic (which they did achieved) but not totally platform-agnostic (not sure if that was ever a goal of COM).
external declaraction would have worked and be understandable but nooo, they had to go fancy pant and call it.... Platform-invoke. Complete with the snooty accent.
if you know what VBA's Declare is, then you've understood what you need to know about p/invoke.
@this my understanding of C++/Win32 is just enough to make Declare statements achieve amazing feats, most of the time, and to crash the host, the rest of the time.
I don't write enough C++ to be fluent in it, either. The PR I provided for the olewoo was my latest fray into C++ and probably the biggest one I made ever. Other times, it was just dumb simple stuff.
I am working on a bit of a multiple part project, the goal of the project is to have a spreadsheet full of order data (order number, customer data, products ordered, prices etc) merged so that the duplicate information is grouped up.
https://gyazo.com/3034782c17256afac40f6a31cd469dc1
^example o...
I already answered a similar question here, about periods . in a name, but I'm unsure about whether the same rule holds for backslashes.
Is it possible to write a UDF in VBA that contains a period in the name?
If the UDF is written in an external library, will the library allow backslashes in f...
What is the difference between the dot (.) operator and -> in C++?
VBA Rubberducking
VBA Rubberducking