« first day (1964 days earlier)      last day (23 days later) » 

12:01 AM
RELOAD!
[rubberduck-vba/Rubberduck] 1 opened issue. 2 issue comments.
[Minesweeper] Games Played: 86, Bombs Used: 42, Moves Performed: 11646, New Users: 11
 
 
3 hours later…
3:30 AM
I see chat was busy today.
Back to work tomorrow. There couldn’t possibly be any fires that need attention after being gone for a week.
They’ll be easy compared to BBQing mom and cleaning out her apartment.
 
 
4 hours later…
7:45 AM
 
 
1 hour later…
9:12 AM
 
 
2 hours later…
10:49 AM
 
11:19 AM
star shower!
 
11:31 AM
> Version 2.4.1.5105
OS: Microsoft Windows NT 6.1.7601 Service Pack 1, x64
Host Product: Microsoft Office 2016 x86
Host Version: 16.0.9126.2282
Host Executable: EXCEL.EXE

The horizontal scrollbar that has been recently added has a few issues.

Initially clicking on an item nudges the horizontal scroll a little so that the icons and start of the text are then hidden from view.

After using the scrollbar and collapsing a grouping, expanding it again makes the scrollbar default to the fa
 
12:05 PM
> As far as I understand it, we cannot use 2019 unless we change the SDK used. OTOH, once we update the SDK, we cannot use 2017 anymore.

The .NET Core 3 and 2019 are already officially released for some time.

So question now is - do we want to move forward on this and require use of 2019 going forward?
 
12:17 PM
> @bclothier

> once we update the SDK, we cannot use 2017 anymore.

Can you clarify? It's possible to create .NET Framework projects that use the new SDK-style format.
> We already are using the SDK style. The limiting factor is the ability to use WPF & WinForms, which .NET Core enabled support for in version 3 and is not backported to Visual Studio 2017. We were able to transition to SDK format earlier because we used Sunburst SDK which had support (sort of) for WPF & WinForms without requiring us to go to 2019. To use .NET Core 3 and thus get support for WPF/WinForms, it must be on Visual Studio 2019.
 
1:09 PM
This line compiles just fine in my Dev Access project, but gives me a compile error when I move it to Prod:
Private Sub web_LoadAutoProxy(web_Request As WebRequest)
#If Win32 Or Win64 Then
the #If.. line that is.
Any ideas why?
I'm running the same Access O365 edition on the same machine - it's just a matter of whether I opened the .accdb file from /Dev or /Prod...
 
what is the compile error you get?
 
(TBH, I need to remove all that code - it's part of Tim Hall's web tools and I'm not using them, but still...)
 
feel like there's more to it than just the 2 lines
also, I'm not sure that the evaluation makes much sense.
 
Compile error:
Automation Error
 
and it highlights that line? Something's off.
 
1:11 PM
Yup, that's the one highlighted.
the whole sub:
 
cut out the entire module, then paste it back.
 
Private Sub web_LoadAutoProxy(web_Request As WebRequest)
#If Win32 Or Win64 Then
    On Error GoTo web_ErrorHandling

    Dim web_Parts As Dictionary
    Dim web_Domain As String
    Dim web_ProxyServer As String
    Dim web_ProxyBypassList As String

    Set web_Parts = WebHelpers.GetUrlParts(Me.GetFullUrl(web_Request))
    web_Domain = VBA.IIf(web_Parts("Protocol") <> "", web_Parts("Protocol") & "://", "") & _
        web_Parts("Host") & ":" & web_Parts("Port")

    ' Cache auto-proxy by domain
 
I guess the intention was to make sure this runs on Windows only and be no-op on Mac???
 
cut 'n pasted, same compile issue.
I just need to pull all that stuff out. I really don't use it.
that will prolly solve the problem
 
should, unless the error is actually somewhere else.
 
1:13 PM
yet it works (compiles) just fine in one .accdb, but not in the other.
weird...
scurries off to sharpen the hatchet and get the hockey mask
 
do you change compilation flags when changing environment?
 
not on purpose
or intentionally
 
Ugh, has anybody of you ever assigned an array to the Value property of a multi-area range.
 
there are compiler flags in VBA???
 
It seems to be really broken.
 
1:16 PM
Yeah there are, and you can set.
 
color me amazed
 
I don't think non-contiguous range is a common scenario enough to be supported well.
 
You can access them in the project properties.
 
I routinely do that to switch between late/early binding
 
oh. who knew?
well, obviously, you two, but still...
 
1:17 PM
The values are copied into all areas and the ordering of every second is completely wrong.
 
Not many, evidently.
Isn't there a facility to get a contiguous range for each area in the non-contiguous range?
 
ah... hatchet sharpener has completed its task. Time to swing it!
 
There is. It is called Areas.
 
I vaguely remember someone saying that it's better to use areas if you need to manipulate non-contiguous range
 
Still, I would not expect a completely mangled order of values in every second area.
 
1:19 PM
That's Microsoft for you?
Sorry, don't know what to say to that.
 
Getting the values will simply yield the values in the first area.
 
but you can iterate over the areas for each sub-range, right?
and thus set the value in each area's range
 
Just stumbled over it while enhancing the documentation for Value.
Their stupid design means that whenever you take a range, you have to do some validation to check that your range is actually of the correct kind.
This is nearly as stupid as having Columns return a range instead of a Ranges object.
</rant>
 
git rm <filename> will remove the file from the project, correct?
@M.Doerner Go! Go! Go! Go!
 
1:34 PM
that's weird... my Duck just disappeared! HEEEELLLPPP!!!
ummm... ghost Access???
whew! one-time thing...
that was bizarre at best.
Note to self: quit making Jason references. Seems to be bad for Access.
 
it is an annoying quirk -- ghost instance takes all the add-ins (not just ducky)
 
I've not had that happen in ages!
 
you should report it if it happens again.
 
I'm happy that I was so confused. For a while, it was an every time occurence, so I knew exactly what to do. Since y'all managed to put the stake through the heart of the ghost so long ago, I was baffled...
 
1:59 PM
Access had crashed, so I'd imagine that's where the ghost came from - it attempting to restart itself, me attempting to prevent it from doing so. It wasn't pretty...
 
yeah, I don't like the new crashing behavior
they copied this from Apple
and TBF, it's still jarring to see something just suddenly restarting out of blue without any acknowledgement that they died.
 
It does seem that much of the state of modern commercial software development is "Oh, look, our competitor has an annoying new feature, let's copy it!"
Just because you can, doesn't mean you should...
 
^
I kind of understand why - nobody pays any attention to "we crashed because null pointer at 0x23847af djflajfl;dsjgklhdfghjkgd;"
but still, I'd prefer an acknowledgement --- "It's OK! I just died but don't worry, I didn't lose your unsaved work!"
or something
 
@this something...
I'd imagine that it's phoning home with the crash report, too, but with no public acknowledgement. I'm sure we all agreed to it buried somewhere 10 miles deep in all the EULA pile
 
Yes, I think the same; the phoning home is a given nowadays. :\
 
2:09 PM
hence duckemetry!
 
but unlike them, we'll be up-front about it
no hiding behind indecipherable EULAs here!
 
naaaahhhh... what's the fun of that? ;)
 
yeah, we need to lose more stars. ;-)
 
What is a TempSccObj[1|2] object in the Access forms collection? I now have 2 of them and a search for ms access tempsccobj gives me links to Access in general and a search for TempSccObj gives me recepies for kombucha
(whatever the heck kombucha is...)
 
do you have anything open?
 
2:16 PM
I have my prod .accdb open and my main form.
 
and I assume the main form isn't named TempSccObj
 
no, no it's not.
 
just as an experiment ?Forms("TempSccObj[1|2]").Visible
if it's false, then set it to true and see what it's
 
interesting. I opened them both in design mode. they look like crash recoveries of a form that I haven't messed with in quite a while.
 
are you using the old SCC integration in Access?
 
2:18 PM
essentially the same thing
I'm using my Import/Export routine.
 
hm. then no clue how it came to be. if you were using the old MSSCCI provider, I can see how Access would create a temporary copy
 
guess that coulda been the issue - not a clean import. I do recall an error several imports ago. Reimported, all was good, didn't notice if it added a form
 
@M.Doerner I’ve dealt with that before. You’re not along in your frustration.
 
you seem to find all interesting edge cases....
@IvenBach How much more before he'll be through with frustration?
 
Somehow, I managed to miss migrating some reporting for this new process to prod. Once I'm sure I've got that working well, the next step is to migrate my git repository to the OASYS file structure/names and use a real tool, not my home-brewed half-arsed attempt.
@this That's why y'all dubbed me head of QA, right? :D
If only I was as good at finding the issues in my own code before releasing to the public
 
2:21 PM
yeah but not just RD. YOu just.... attract.
 
it's my magnetic personality
 
@FreeMan ah, tut, tut - that's just the principle - nobody can see their own flaws.
 
@this <sings>It’s only just beguuuuun.<\sings>
 
so. very. true.
@IvenBach lol
Muuuuuug!!!
 
2:24 PM
@FreeMan 1408 reference. The only thing good about that lame movie was that little diddy.
 
eh? (not even sure what movie that's from, but I recognize it and did sing it in my head.)
 
it stars John Cusack. That's all you need to know.
 
> Has it been confirmed that VS2019 can actually build Rubberduck? If so, then all we need is a pull request to make it happen.
 
@MathieuGuindon AFAIU, the type lib generation when we build the project is not yet supported in Core.
 
VS2019 is still a no-go then
 
2:33 PM
So, we have to find a way to get the meta project working.
 
@MathieuGuindon not necessarily, we just can't go to Core
 
We still have to investigate.
 
then again MS claims that our usecase is supported.
 
@Vogel612 How will we deal with the WPF problem, then?
 
> I already have a branch that i have not yet pushed building using the extra SDK and it can build 2019 just fine. I need to test it on 2017, however and handle some other mysterious warnings [ref](https://github.com/onovotny/MSBuildSdkExtras/issues/193#issuecomment-544973179).

Using extra SDK might be sufficient to allow us to support both 2017 and 2019, but that needs to be tested.
 
2:35 PM
@M.Doerner target Framework...
 
@M.Doerner That's if we are using Core rather than framework. That's a separate issue from using SDK.
 
AFAIU, the framework version does not support WPF with SDK style project files.
 
um. That would be news.
I always understood that the UseWpf and UseWinForms property to enable us to build using SDK project targeting framework or core.
 
Then why did we never get proper WPF builds before?
 
because we need MSBuild 16 to provide that new support.
and it exists only in 2019
 
2:37 PM
I mean, without sunburst.
OK, then I misunderstood.
 
IIRC, @Hosch250 was working on getting a 2019 build working. I don't recall his final result.
Don't know if he'll get the ping here or if someone may have to contact him out of channel
 
To put it other way, if you want to use UseWPF/UseWinForm property, you must be using MSBuild 16 and consequently VS2019.
If we want to keep supporting builds on both 2017/2019, then we need to use alternatives, which I mentioned earlier in the issue.
 
@FreeMan same problem as @this encountered
 
The only thing is that the alternatives aren't official support so....
That's why we need to make a decision whether we want to cut off 2017
The extra SDK seems to work. Since it's basically just extension of Microsoft's SDK, it might be all that we need but I have to see if I can build it off the 2017 first.
 
@Vogel612 OK. I just remembered that he was working on it.
 
2:46 PM
Personally, I do not care whether VS2017 will get cut off. I just need some version to still work.
3
 
Ok, good to know. If we knew others' opinion, that'll help.
I don't want to unilaterally force everyone to 2019.
@Vogel612 do you remember why we have this line: '<RunCodeAnalysis>true</RunCodeAnalysis>'
 
3:02 PM
@this no, I thought that was conditional??
 
The thing is that I think it doesn't mean what we think it means.
I thought it was something to do w/ extra sdk but now I think it's actually a 2019 thing - to warn about using deprecated FxCopCmd
Gonna love the intuitive names Microsoft give their build properties.
 
~sigh
 
IKR?
 
just nuke it then :)
 
Yeah, just wanted to be sure there wasn't reasons that I didn't know about
 
3:17 PM
so it seems you found the reason we get a "deprecated FxCop warning"
 
fat-fingered a close ...
 
@Vogel612 yeah I just confirmed that.
 
> Hey @mai-am it's been a week, is there anything I can do to help you?
 
3:21 PM
That said, the real litmus test is yet to come - I need to put it on my 2017 vm and see if I can builld it there
I recall the extra sdk was the first one you tried and it didn't work but I can't remember why.
it might have been an older version, though.
 
gee, I'd have to dig through a week of transcript to have a chance at recalling why ...
probably to do with designers and multi-step builds
 
and it was also over a year ago, so I'm basically starting from scratch in the hope that things got better between then an dnow
 
> Oh dear! I'll take a look at this later today.
 
4:15 PM
Any new RD features in the last week I've missed.
 
Star storm, @IvenBach
 
I saw those 3 today.
 
@IvenBach we got a horizontal scrollbars, too?
 
hrm... I've reorganized my Access project git repo based on the files exported by OASIS-SVN instead of my own Import/Export routines. Everything went fine until I tried to merge.
 
For all the code panes?
 
4:19 PM
I've got conflicts on binary files:
$ git merge FileReorg
warning: Cannot merge binary files: SatSummary.frm (HEAD:SatSummary.frm vs. FileReorg:Forms/SatSummary.layout)
warning: Cannot merge binary files: Master.frm (HEAD:Master.frm vs. FileReorg:Forms/Master.layout)
warning: Cannot merge binary files: DataMove.frm (HEAD:DataMove.frm vs. FileReorg:Forms/DataMove.layout)
Auto-merging Forms/SatSummary.layout
CONFLICT (content): Merge conflict in Forms/SatSummary.layout
Auto-merging Forms/Master.layout
CONFLICT (content): Merge conflict in Forms/Master.layout
 
and if you haven't gotten them, default member inspections is most important.
those are not binary files
whack the git
 
How do I resolve those? Basically, I don't care about the old version of the file, just want to replace with the new
Yeah, I know they're not binary but git thinks they are, so... :/
 
33 secs ago, by this
whack the git
 
@this oh yeah, bunch (or at least a couple) new inspections!
 
IDK why git does that to you. Never has happened to me. :\
 
4:21 PM
@this can you speak a bit louder for us slow folk who don't speak the git so good?
2 hours ago, by this
you seem to find all interesting edge cases....
it's my job...
I found that git diff --text <file> will force it to give output, but it's not pretty...
what does "whack the git" mean, what do I whack it with, and where, exactly, shall I apply the whack?
 
I don't have the command off the cuff (I use the tortoise) but the answer would be to take the new files as the winner
huh, merge tool isn't builtin?
0
A: git: resolve merge conflicts by accepting my changes

TimmyUse a merge tool. Here is one example: git mergetool --tool emerge commands: a- choose change in A b- choose change in B n- next change p- previous change q- finish merge info on emerge In the future I would only merge into master. have a Master and Develop branch, then branch off of dev...

 
this, if I read it right, says git rm <old file>, then git add <new file>
 
.... i use the tortoise....
#lazy
Re: binary thing....
68
A: Override git's choice of binary file to text

Greg HewgillThe way files are actually stored inside the Git repository is not relevant to how they are treated when displayed. So the git diff program, when asked to compare two files, first obtains both complete files from the repository and then runs a difference algorithm against them. Normally, git dif...

 
I see this:
I'm using Git GUI since it's already installed with my Git bash...
Do I "Sign Off", Commit, Stage changed?
 
there should be an option somewhere to say "stuff it and take my changes"
 
4:33 PM
None of those screams "declare a winner and move on".
 
uh
use Tortoise?
 
yeah, I looked, didn't see anything obvious...
 
did you check right-click menu?
 
yeah, nothing obvious there either.
derp. Didn't right-click in the right place
 
when in doubt, right-click
 
4:38 PM
OK, it says "current branch: master" and gives me an option to "Use remote version" or "Use local version". I presume "local" = master branch and "remote" = branch I'm merging from?
 
i think it's teh other way around
 
well, of course...
weirdest part is that I git rm *.frm (I thought) then git add Forms/*but it thinks I mvd *.frm -> *.layout
 
I could kind of why it'd think that
i assume in your original system, you had a .frm that contains both layout and code
but with OASIS, it splits into 2 files
normally, layout comes first before the code, so in the original .frm the first few lines will look identical to the new .layout, so probably git notices it and thinks, it's a rename operation
 
Even though I explicitly removed the .frm? That's... almost Microsoft levels of "helpful"
sees evil Clippy lurking in the shadows
 
I've noticed that git isn't that bright when moving/renaming are involved
 
4:44 PM
and yet, this behavior is trying to be smart
 
but then again, it's very tricky thing to catch since OS doesn't exactly tell you, "oh, hey, that file was originally named X but the luser changed his mind and named it Y"
 
in this case, nothing was renamed. the original *.frm were deleted both from disk & git, then the .def & .layout were added.
le sigh...
 
you could always write to Linus....
 
I'll have words with him!!!!11!!
weird, using git GUI, it doesn't matter whether I select "Use Remote Version" or "Use Local Version" it says:
Force resolution to the other branch?
Note that the diff shows only conflicting changes.
DataMove.layout will be overwritten.
This operation can be undone only by restarting the merge.
 
the other branch? Awesome UX right there.
 
4:50 PM
Actually, that was from "Remote". If I choose "Local" the first line is: Force resolution to this branch?
 
same problem. What's "this"?
 
ddg's tortise git
I'm guessing that "this" = "local" and "other" = "remote" since that's the wording diff based on the option I chose, but...
 
You will appreciate the tortoise.
Still. as a rule, i avoid the use of pronouns in such verbiage.
English just doesn't work with more than one. Maybe two, if you use different genders but it breaks down quite easily.
He told him that he had to go and he would stay while he was away. He will organize the things in the meanwhile he is working. He will see him again very presently.
 
Sounds like my wife.
Except she just starts on something like that out of the blue and with no context or warning.
 
Tell her that she has a horrible UX.
I'm sure she'll appreciate the feedback... right?
:-D
 
4:56 PM
eh... no, actually, her UX is quite nice. A couple of quirks here and there, but...
 
LOL
 
back OT...
setting up tortise git it's asking about Authentication & credentials & SSH & stuff. Is that only for GitHub type access?
 
no. you may have a local git server that requires authentication, etc.
if you don't use ssh & stuff, you can just accept the default and move past
 
ah. I have a network location that I can access with AD credentials, so skip it I shall
having used only the command line, that was kinda odd. especially with the turtle doing front flips.
 
gonna admit, that's an impressive stunt, no?
 
5:06 PM
never seen it done before
I've seen a house fly, and I've seen a horse fly, and I've seen a pig fly, but I ain't never seen an elephant fly tortoise flip
lunch!
 
@FreeMan You and me both.
 
lol
@this is undefined. dang! missed a great opportunity. :(
 
Within Rubberduck.Core/UI/Inspections/ .local and project.json are untracked. I don't remember modifying these files.
 
5:24 PM
.local should be in .gitignore
project.json... idk
 
not sure if we added a .json. if it's not in GH, then it's VS' doing
 
5:55 PM
i have the final iteration (i think) of the code ima use
that i got from @Senipah
 
6:41 PM
yeesh... finally got the Win10 update to start installing itself. 2 hour update time - unable to use the machine while it reboots 487 bajillion times - nice way to end a WFH day...
 
could be worse. You could have been on fire while it insists that you wait patiently for it to finish doing its thing.
 
not a bad thing, really. It's a 2-hour vacay. The boss did hers first thing in the morning yesterday. Just glared at me when I walked into her office - was astounded that it was going to take so long*! Another person was basically napping at her desk while it did its thing...
And, since we're moving all the way to build 1803, we get to do it again in 13 months... :/
* never mind that there were WARNINGS that it would run 2 hours...
 
7:26 PM
> **Rubberduck version information**
Version 2.4.1.21624
OS: Microsoft Windows NT 6.1.7601 Service Pack 1, x64
Host Product: Microsoft Office 2013 x86
Host Version: 15.0.5023.1000
Host Executable: EXCEL.EXE

**Description**
The images are slightly different sizes setting off my OCD. Spacing for text between UserForm and Standard module and Class Module shows the different sizing.

**To Reproduce**
Steps to reproduce the behavior:
1. Right click within Code Explorer > Add

**Expecte
 
Feels good to be somewhat back at normalcy and working.
 
See, that's why I don't do WPF. ;-)
It feels completely backward to me that I have to specify the size of a submenu so that it can look like its parent menu.
 
IIRC it should inherit from the parent.
Didn't dig into the code to see how it's set up.
 
for whatever reasons it didn't.
 
7:49 PM
@this I've seen that before.... VS2019 has a habit of "suggesting" that code analysis might be nice (in one of those yellow banners) and "helpfully" adding that property if you click Yes. So I suspect it may sneak back in...
 
Oh?
 
Just opened my first PR to the VBA documentation.
Curious to see how the process will work over there.
 
I think @MathieuGuindon has done this before, so he'd know.
For the .Value?
 
For things around Range.Item.
Cells, Columns, Rows
Howevre, the main thing is to actually provide a documentation for how Item works for different numbers of arguments and types of ranges.
 
@this Yeah, it did it to one of my work projects...
 
7:53 PM
@M.Doerner Very nice! They shouldn't have to go to various SO threads for that rather surprising behavior.
@mansellan which only makes it even more bizarre since it's... deprecated by 2019...
 
Dear VS2019. For the seventeenth time of asking, no. I would not like to disable Resharper Ultimate 2019 to improve performance. Could you please quit asking now? Kthxbye.
 
that notification bar is the new Clippy
 
@this odd indeed...
 
isn't there don't tell me again?
at least it works in 2017....
 
I also added the multi-cell behaviour of .Value to its documentation including an example.
 
7:55 PM
@this Yep. Doesn't seem to work (at least not for me, reliably)
 
that only motivates me to want to keep 2017.... :\
 
> An issue was raised after the previous scrollbar for the Code Inspection window was added in by me. I've done a fix for it now (going to make a new pull request which will close the issue, #5237) and I'm going to update this pull request with the fix as well. Sorry about that!
 
8:11 PM
w00t! Got my Core 3 WPF app deploying over ClickOnce :-)
 
@mansellan so it wasn't click once?
 
@this It was many more clicks than once :-)
Turns out it hates embedded manifests
I guess it predates them...
 
> FWIW, I don't see the need to support 2017 any more, 2019 seems plenty stable.
 
@Duga other than the over-enthusiastic banner...
 
8:20 PM
GTK. the 2015 to 2017 was underwhelming.
and judging by stars on Max's comment, I guess that's 3 (4?) - nil in favor of making RD 2019-only
 
3 - one of them stars is mine :-)
 
<~ one here too
 
gasps Mat is in favor of 2019? checks if sky has fallen
In that case I might just forget about using extra sdk and just use the plain SDK with built-in UseWPF & UseWinForm properties. That should work and is 100% supported instead of jerry-rigged
 
Sounds good to me.
 
fwiw, with a big work project, I tried switching to net472 in the new SDK, and it didn't work. So I was worried that it had a bug, but I just tried with a new WF/WPF project and it seems fine, so it's probably something else in the codebase.
 
8:25 PM
Maybe we should wait until after Hacktoberfest to make the switch.
 
yeah good call
 
I know for a fact that extra SDK buils fine but using its custom properties
(and without the hacky workaround section we added to make WPF work, too)
 
what is this extra SDK
 
the extra sdk does support the Use** properties so I guess we don't have to not use the extra SDK but... IDK.
@M.Doerner What prompted me was my failures to reproduce Freeflow's crashing with build 5071. It was not something simple as referencing an errant library.
 
[rubberduck-vba/Rubberduck] build for commit 8c3e28b4 on unknown branch: AppVeyor build succeeded
 
8:27 PM
driving, bll
 
my 2017 VM has the wrong Office bitness, and my VM with 64-bit Office has VS 2019 so....
But yes, I agree with holding back the change until end of the month.
 
8:38 PM
@M.Doerner agreed
 
9:11 PM
> I've made the fix now. In regards to the first problem you mentioned, I noticed that if you expand an item and click the icon, the scrollbar won't move and you can still see the icon and start of the text. However, if you click the text, the scrollbar moves. This is because the icon is in a column of its own (Type) and therefore separate from the text (Issue). By default it will center in on a column. I'm not sure if there's a way to override this default behaviour, but I can look into it.
 
i seem to recall Comintern diong some kind of tricks WRT the click events
 
Reading Remarks for InputBox triggers my inner @this. Specifically "For example, for an input box that can accept both text and numbers, set Type to 1 + 2." should be 1 or 2.
Achievement Unlocked: You've awoken my inner pedant.
 
9:50 PM
To share some .NET news, there is one unplanned bit in that. telerik.com/blogs/dotnet-is-dead-long-live-dotnet
 

« first day (1964 days earlier)      last day (23 days later) »