« first day (1416 days earlier)      last day (1764 days later) » 

12:01 AM
RELOAD!
[banane-io/PDB] 1 commit. 1 closed issue. 1 issue comment. 110 additions. 1075 deletions.
[malachi26/Memer] 4 commits. 16 additions. 16 deletions.
[rubberduck-vba/Rubberduck] 6 opened issues. 1 closed issue. 3 issue comments.
 
 
5 hours later…
5:26 AM
Morning or locale-appropriate greeting
 
 
6 hours later…
11:24 AM
> So it turns out I was wrong about using DLL calls. As an office commandbar, the only way is option 2.

It's possible that the unreliability is due to not registering the correct clipboard formats ("Toolbar Button Face" and "Toolbar Button Mask" in en locales). I also have an idea on how to make it locale-agnostic.
 
 
2 hours later…
1:13 PM
> Just one more thought - the PasteFace command strongly impiles that it's UI-related task. It may be necessary to ensure it is only executed on the UI thread, which you can do via the IUiDispatcher.InvokeAsync.
 
1:40 PM
> @bclothier not necessary here. In general, you need not worry about COM calls happening in the wrong thread. They will be marshalled to the correct thread for you automagically. (This is somewhat different to the TypeLib API, due to the ~~~hack~~~ magic we use to grab the initial COM object)
> Having to use the clipboard for this is a horrible, cumbersome design. I suspect the issues on my machine were something to do with the Office clipboard manager (in Office 2003) interfering with the API calls. If having the icons is important enough, we could potentially hook the clipboard API calls that VB6 makes at this point, and redirect them to our own .NET implementations, so in effect not using the clipboard at all (remembering to unhook immediately after the PasteFace call of course)
> Having to use the clipboard for this is a horrible, cumbersome design. I suspect the issues on my machine were something to do with the Office clipboard manager (in Office 2003) interfering with the underlying clipboard API calls. If having the icons is important enough, we could potentially hook the clipboard API calls that VB6 makes at this point, and redirect them to our own .NET implementations, so in effect not using the clipboard at all (remembering to unhook immediately after the Past
> I'll sort this once the main PR #3935 is merged. I think I can remove the dependency to the interface whose GUID changed between VB6 and VBA, and thus make the TypeLib API agnostic to both.
 
2:15 PM
> This is going to need some kind of clipboard inspection. So far I have done the following:

1. Outside of RD, created a custom CommandBarButton and pasted an image into it*
2. Back in RD, programatically located this button and called Clipboard.GetData("Toolbar Button Face") and ("Toolbar Button Mask"), sent resulting memory stream into byte[] arrays.
3. Clipboard.Clear
4. Clipboard.SetData x2 (using same formats)
5. Button.PasteFace

Step 5 fails with a cryptic COM exception. But - us
> Oh, and I agree - dumping the user clipboard is poor UX. It seems to have been the accepted way back in early COM add-in days, but doesn't mean it is now.
 
2:34 PM
> FWIW, in older versions of Access whenever you paste in an image, it got wrapped with EMF metadata and was saved with that extra wrapping. That essentially meant the picture was saved differently from its original format. It is very possible you are observing a similar thing going on here; what you are getting out contains all metadata and the `PasteFace` won't have none of that; it only wants raw image file?

Ref: http://www.lebans.com/image_faq.htm
> Closing as duplicate then
 
3:00 PM
Anyone --- I think I need a sanity check. I have this feeling I'm fighitng the mock tests, not the actual behavior. Does this look right for setup?
        [Category("Resolver")]
        [Test]
        public void Identify_NamedParameter_Parameter_FromExcel()
        {
            const string code = @"
Public Sub DoIt()
    Dim foo As Variant
    Dim sht As WorkSheet

    foo = sht.Cells(ColumnIndex:=12).Value
End Sub";
            var vbe = new MockVbeBuilder()
                .ProjectBuilder("TestProject", ProjectProtection.Unprotected)
                .AddComponent("TestModule", ComponentType.StandardModule, code, new Selection(6, 30))
 
3:13 PM
I also tried the MockVbeBuilder.BuildFromSingleModule() with referenceStdLibs:true as well. In all cases sht's declaration has AsTypeDeclaration set to null, which is totally wrong.
 
> We have a couple of wiki articles on the parsing process, great!

But unfortunately, for people to be able to contribute to resolver fixes, I think we could all benefit from some high-level map for the resolver. As it is, it involves a large number of classes and a very deep traversal where a binder may resolve expression, invoking yet another binder and so on.

And we also have multiple passes (e.g. compilation pass, type annotation pass (which I should note that has nothing to do with
 
@this As far as I can see, you never add the reference to the Excel library to the project in the test.
Only the VBA library reference gets added if you set referenceStdLibs ti true.
If you want to see the Excel library, tou have to add the reference yourself.
 
4:27 PM
VB folks, why is this so down-voted?
-2
Q: Abridgment VB.NET Code

Jada Developeri would like to know if someone could do an Abridgment for this code : This is the output results : Moneyresultsell.text = 98524232 SellCopper = 32 -- last 2 numbers SellSilver = 42 -- numbers after the 2 last numbers SellGold = 9852 -- other numbers after 4 last numbers My Code works good ...

@MathieuGuindon ^^
 
@SimonForsberg uhm, no context whatsoever, not even a scope, terrible title, ...
 
@SimonForsberg ^^ as per Mathieu Guindon's remarks and it is not the entire code either. And is the "--" a recognised term in, for example, "32 -- last 2 numbers" ? A test sample and explanation of output would have given some context.
 
@QHarr @MathieuGuindon Where are the comments?
 
@SimonForsberg Good point well made
 
4:42 PM
Welcome to Code Review. As πάνταῥεῖ said, a little bit more context would me great, e.g. "I'm given an amount of coppers and want to transform it into the number of gold, silver and copper pieces, where a silver piece is worth 100 copper pieces and a gold piece is worth 100 silver pieces. It works for any string/some strings/...". Context is an important part of the question, so make sure to edit it into your post. — Zeta 9 hours ago
Looks like a mod removed them?
ResultX are all String variables. Does VB.NET allow you to divide a string by 100 like this? This post needs more context, and more of the code.. we don't even know what the method is named or what its purpose is, only that you'd like it shorter. Please read How to Ask. — Mathieu Guindon 34 secs ago
 
@MathieuGuindon Well okay, I meant "Why are the close votes for code not implemented?"
 
@M.Doerner wait, so this testLibraries:new[] { "Excel.1.8.xml" }); does nothing?
 
It loads the declarations.
You have to do both.
 
and it did.
I see....
let me see if I can find the syntax to add reference.
 
@SimonForsberg afaict the code is borked
 
4:49 PM
I have to say it doesn't make much sense to merely load declarations and then do nothing with it.
 
It should be on the ProjectBuilder.
 
@MathieuGuindon Ok, a comment explaining that was missing - you added one, thanks.
 
that means my search for the cause was wasted.
 
I agree that the test setup is not intuitive regarding referenced libraries.
I had similar fun a while back.
 
so I also have to provide the path and the version, too.
that's too much to go wrong.
do you know if the path should be the one to the xml or the actual one as we'd see in real project?
hopefully this does the trick... .AddReference("Excel", MockVbeBuilder.LibraryPathMsExcel)
(judging from other uses of the AddReference)
 
4:57 PM
ok, making progress... I can now set Office8 menu icons from a byte array. Just got to figure out how to get the right byte array from a given bitmap.
 
really think the .AddReference should have a overload to take an enum so we can eliminate all the guesswork WRT the path and version. Those are not details I'm very interested when I'm writing a test
now i can make a bit more progress finally.
Hmm..... Interesting....
Message:   Expected Parameter, resolved to Parameter
  Expected: <Rubberduck.Parsing.Symbols.ParameterDeclaration>
  But was:  <Rubberduck.Parsing.Symbols.ParameterDeclaration>
so a Parameter is not equal to Parameter, gotcha!
ah, because the test message doens't reflect what I'm actually comparing.
 
5:43 PM
> I've reviewed this and I think this is actually more complicated than it seems.

Consider those 3 cases:

```
Public Sub foo()
Dim sht As Excel.Worksheet

sht.Paste Link:=True
End Sub

Public Sub foo1()
Sheet1.Paste Link:=True
End Sub

Public Sub foo2()
Dim v As Variant
Dim sht As Excel.Worksheet

v = sht.Cells(ColumnIndex:=12)
End Sub
```

In the first case, it resolves correctly and shows as `Parameter` when selecting the `Link`

In th
 
6:02 PM
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3893?src=pr&el=h1) Report
> Merging [#3893](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3893?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/14743dc32ef02938b569b841fe94e8d250217b72?src=pr&el=desc) will **increase** coverage by `0.05%`.
> The diff coverage is `100%`.


```diff
@@ Coverage Diff @@
## next #3893 +/- ##
=========================
> Note that the PR #3893 adds a failing unit test which is currently ignored; Identify_NamedParameter_Parameter_FromExcel_DefaultAccess that covers the third case. We also have a (currently passing) unit test for first case (Identify_NamedParameter_Parameter_FromExcel) to prove that external references are being resolved correctly. Originally I was going to fix this in the PR #3893 because it seemed similar enough but based on the finding above, I think a separate PR is best.
[rubberduck-vba/Rubberduck] build for commit 9d82c0cb on unknown branch: AppVeyor build succeeded
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3893?src=pr&el=h1) Report
> Merging [#3893](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3893?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/14743dc32ef02938b569b841fe94e8d250217b72?src=pr&el=desc) will **increase** coverage by `0.05%`.
> The diff coverage is `100%`.


```diff
@@ Coverage Diff @@
## next #3893 +/- ##
=========================
[rubberduck-vba/Rubberduck] build for commit 9d82c0cb on unknown branch: 57.69% (target 0%)
 
 
4 hours later…
10:05 PM
 
10:52 PM
> FWIW I cannot reproduce this anymore so I think we can close this issue unless anyone have a different MCVE where crash still happens?
> I think this should be closed, since we already merged the PR #3876 (which aforementioned #3875 was merged into).
 
11:22 PM
> Using the same file that was provided above, and deleting few random classes, I no longer can reproduce the crash when trying to view the same property mentioned. Unless someone can provide show otherwise, this will be closed.
> Since we already addressed this with the PR #3739, this can be considered to be partially addressed. Furthermore, we have an open issue that's more recent -- #3862, so I'm closing this to minimize duplication.
> Note the comments in #2826 where we discuss the idea of stairway pattern. We should review and ensure we apply where it is warranted.
 

« first day (1416 days earlier)      last day (1764 days later) »