> Same problem here: after a fresh installation (my first RD install), I permanently see the same message _Rubberduck doesn´t seem to see anything yet_ in the _Code Inspections_ panel.
I have ticked the _Run inspections automatically on succesful parse_ checkbox, and have clicked the refresh button several times.
> Same problem here: after a fresh installation (my first RD install), I permanently see the same message _Rubberduck doesn´t seem to see anything yet_ in the _Code Inspections_ panel.
I have ticked the _Run inspections automatically on succesful parse_ checkbox, and have clicked the refresh button several times.
> @oscarda Does your code compile? Our parser seems to have a problem with line 39 of the module `Analizador`.
The refresh button in the command bar should show some localized form of _Parser Error_. Moreover, next to it, there should be a small red icon, which you can click to get a list of the parsing errors. Double clicking one should navigate to the spot our parser failed.
> **Rubberduck version information** Version 2.5.1.5557 OS: Microsoft Windows NT 10.0.14393.0, x64 Host Product: Microsoft Office x86 Host Version: 16.0.11929.20648 Host Executable: MSACCESS.EXE
**Description** After fresh installation, and clicking on any rubberduck 'refresh' icon, TestExplorer gets stuck showing non-stop the 'processing' rubberduck spinning ring. Also, all the TestExplorer menus are disabled, appart from 'add Test Module', that works correctly.
> That the test explorer animation does not stop upon a parser error seems to be a bug, indeed.
As I also wrote in a reply to your comment in #4980, the reason why everything stays deactivated is that there was a parser error. You can see that in the command bar. Clicking on the red button will allow you to navigate to the parser errors RD encountered. Based on the logs, this should point you to line 39 of the module `Analizador`.
Note that we need to parse the code in order to make sense
> @MDoerner thank you very much. Though my code seemed to be working, rubberduck parser had found two issues. Once I have solved them, everything is working correctly. I hadn't noticed the parser error message and icon on the command bar. 
Most grateful for pointing me in the right direction!!
> Thank you @MDoerner!! As you point out, once I have solved the glitches in my code (spotted by Rubberduck), the parser can finish correctly, and the refresh progress ring is not stuck any more.
By the way, the _Code Inspections_ tips are most helpful. I'm impressed with Rubberduck and the excellent team behind it!! Best wishes!!
> I reopen thins because the the eternally spinning animation in the test explorer really is a bug. In case of a parser error, it should stop and revert back to the initial state.
> @oscarda One side note regarding the previously undiscovered issues in your code. In the VBE's options, there is an option to compile on demand, which probably is checked. This has the effect that the VBE essentially only compiles what is needed to run the code you are trying to execute. This can mask issues in other modules not necessary for what you run. So, our recommendation is to turn it off and let the compiler always compile the full project on execution, or more precisely, all uncompil
> Version 2.5.1.5676 OS: Microsoft Windows NT 10.0.18363.0, x64 Host Product: Microsoft Office x86 Host Version: 16.0.13530.20440 Host Executable: EXCEL.EXE
A function call FNNAME(a) is raised as a Code Quality Issue, local variable FNNAME is not declared. The project compiles. The module has Option Explicit Option Private Module The module containing FNNAME does too. Making the fn Public does not change the issue. Moving the function into the same module as the caller, and click
The code below first searches for the first searchText and deletes all rows that precede it to establish a range for a table object. Once the table object is created, it's filtered by unnecessary fields. After ensuring the searchText is in the first row (header), it deletes all visible rows below...
I saw a few threads over the Internet, but no one explained :( Debug.Print ThisWorkbook.Sheets(1).Range("A1") Is ThisWorkbook.Sheets(1).Range("A1") // return false. Maybe someone here knows whats going on Range+Is... :)
It seems that the problem with ridiculous result of Is occurs only with Ranges
@HackSlash How will it bomb please? I thought HTMLFile was different. It is older (like <=IE8) and exposes far less methods than the early bound MSHTML.HTMLDocument
I am not sure if I understand ok: so this strange result of 'Is' is caused by range's default member - .Value? It seems there is no other object in VBA with the same behaviour. Is it the only exception?
But why there are 2 different object ONLY for Range object in this case? E.g. if declaring two different variables ThisWorkbook.Sheets(1) - the Is returns true
Sheets(1), which is actually Sheets.Item(1) is just a lookup in the Sheets collection of the workbook, i.e. you look for an existing object.
On the other hand, range objects need to be generated based on the input anew; it is completely impractical to have them lying around for every possible input.
If you got the same object, then some cashing would be involved, but that is apparently not the case.
One further point is that a range object has more internal state than the underlying range. E.g., it saves whether it consists out of cells, rows or columns, which is wholly another problem with them.
You can observe that by looking at the behaviour of Item on ranges obtained via Cells, Columns and Rows.
"a range object has more internal state than the underlying range" Could you write this in simpler english, please? This is very interesting, but unfortunatelly my english isn't very good... Thanks in advance. I am trying to learn about the difference with Range object itself.
What I meant is that the range object contains more internal information than the range in the worksheet is refers to.
The state of the range it refers to consists of the value, formula and address of the cells, among many other pieces of information.
In addition, there are other kinds of information that have nothing to do with the referenced range, like whether you are looking at it as a collection of cells, of columns or of rows.
You really would not want to have this additional information/state shared between all values returned from a function. So, it makes sense to hand out individual objects instead of always the same cached one.
I must read all your comments one more time carefully. It seems like worksheet object has a lot of "additional information" e.g. Cells collections too, that you can refer to, but its behaviour with "Is" is different than Range
VBA Rubberducking
VBA Rubberducking