@this that's a separate thing - "sheet accessed using string" means to warn about a missed opportunity to use a sheet's CodeName; implicit ActiveSheet refs are flagged by another inspection
> Thanks for posting the log based on the new prerelease. It seems we are missing an exception handler on the inspector; the exception is thrown when adjusting the caption of the refresh button when running inspections.
@mansellan Do I remember correctly, that VB6 uses the old office object model?
If that is the case, the root cause of this problem might be that the corresponding library is not there for some reason. Office 2010 already uses the new object model.
> Thanks for posting the log based on the new prerelease.
It seems we are missing an exception handler on the inspector; the exception is thrown when adjusting the caption of the refresh button when running inspections.
@mansellan Do I remember correctly, that VB6 uses the old office object model?
If that is the case, the root cause of this problem might be that the corresponding library is not there for some reason. Office 2010 already uses the new object model.
@MathieuGuindon copy the image, save to desktop/"pictures" directory on local, click "upload" button --> browse to local image. Eliminates accidental issue submission on GH, hosts the image at SE's imgur instead of GH's... wherever GH hosts images.
^ (On posting images to chat)
@Feeds "Your unsubscribe request will be processed in 7-10 days." Very, very bad
@BZngr I think my xaml tweaks were a wee bit excessive, I removed a number of Name attributes and only noticed the ElementName bindings later -- I'll have a PR tonight to fix it, including the datagrid for the encapsulated fields. Quite a bit of code will be vanishing though, hope you don't mind: making the ViewableEncapsulatedField inherit ViewModelBase and the interface extend INotifyPropertyChanged was the missing piece... apologies for not spotting that earlier in review :/
I think that'll be easier to find any boneheaded mistake I may have made with the changes, too. Keep in mind that visually, nothing should have had changed; all I intended to do is to consolidate everything into a meaningful style definition.
There were few minor changes, though - the most visible one would be the changing the lone AliceBlue used by "nothing to see" control to use the SoftBackgroundColor which is a shade lighter since I didn't feel like justifying a SoftBackground2Color
@this hm, if that's the AliceBlue background in the EncapsulateField control then it shouldn't have made it to Next -- was just me adding a bogus background to see what I was doing in the designer... and forgot to remove it
@this huh wait a sec, are you saying you got theming to work?????
can we hijack the painting of the properties toolwindow and turn white to some shade of gray?
in other news, there's a scheduled power outage tomorrow... which happens to be my work-from-home day. I'll have to shut down my garage server tonight.
@MathieuGuindon in theory, it'll work. I can't say there will be theming for the toolwindows itself but all WPF elements should be theme-able because in the PR, they all now use references.
It's OK if they use a SystemColors as WPF lets us redefine a SystemColors, AIUI.
but it's not as OK to have White used both as a caption foreground color and as a background in different places... redefining White in that case would be.... confusing.
@Duga wondering if this is down to install order. installing modern office after VB6 might mean the commandbar redirects don't get applied correctly...
it sucks, but Microsoft explicitly says non-chronological installs is an unsupported scenario and can break things. installing.md should mention something about installation order
Clarify I was referring to the edge case where the Office 8 library exists but is not registered
A bit hard to see how that could possibly happen for VBA host since VBIDE host itself will take care of that. But with VB6, well, it's not that enthusiastic about housekeeping, it seems.
Long story short, someone started a reimplementation/bundle of a bunch of Linux commands (Busybox, for the Linux-familiars here), and licensed it under GPL to try to encourage companies to try to force companies to actively contribute to the Linux ecosystem.
After actively going after companies with lawsuits for violations for several years, he realized all he was doing was pushing people away from Linux entirely instead of getting them to give to the ecosystem.
So now he's stopped managing that project and is implementing a competitor under a more permissive license.
He's said part of the reason for the effort is so companies can use his software and give back as they are able instead of being forced to either give or leave, and he's going to do whatever it takes to stop the lawsuits.
@MathieuGuindon I'm looking forward to seeing the changes and learning a a lot. I expected there would be a lot of changes (or vanishing code) in the view model and ViewableEncapsulatedField.
> This is almost certainly due to the order in which things were installed. Microsoft advises that side-by-side versions of Office must be installed in chronological order, as otherwise the COM redirects don't get applied correctly. The same thing has probably happened here - if VB6 was installed after Office, it won't have the Office 8 commandars redirecte
I think the harder part is the case where you need a specific version of a system DLL that must be in specific location but you need the host OS to have the latest version.
That's one of my fun thought experiments -- could you actually construct a superconducting computer, and if you did, how would you connect it to the internet.
My hunch is that it'd have to be by wireless or something similar - running a warm wire into a superconducting computer seems.... messy, but I don't know what the ramifications actually are.
[rubberduck-vba/Rubberduck]bclothier pushed commit ffc7511e to next: Replace all dynamic references to static to just static and rearrange style to avoid raising errors due to defining it later in the XAML.
[rubberduck-vba/Rubberduck]bclothier pushed commit 7d09b047 to next: Partially revert the changes where SystemParameters are used; they cause exceptions at startup when statically referenced.
Manual editing was done to the XAML file to ensure that styling reference was preserved.
[rubberduck-vba/Rubberduck]bclothier pushed commit d84a12f1 to next: Revert the StaticResource reference for SystemColors; it causes settings dialog to not open consistently. Also, split all colors & brushes into its own file.
@this Yeah... it's a balmy 25°F now, but it gets well into the 90s in the summer. I might have a hard time arguing for a dedicated A/C duct to the garage...
ignore:
# as requested by MDoerner, because they aren't really testable
- Rubberduck.VBEEditor
- Rubberduck.VBEditor.*
# it makes no sense to track coverage on unit-tests
- RubberduckTests
# xaml files are not checked for coverage
# AutoGenerated files are not contributing to coverage
- **/*.Designer.cs
The ignore instructions don't need to say it because they already aren't checked for coverage. In fact, I don't think they can be since they are compiled away.
The ? wildcard character matches a single character.
The * wildcard character matches zero or more characters.
The ** wildcard character sequence matches a partial path.
hm, OK. Feels silly considering that GH already has the diff, so I'm looking at codecov to see how coverage improved/didn't improve, not to see the diff.
@Hosch250 don't you love mushing together different "languages" together!
Hence the quotes around the word language. I find it very annoying because there are cases where you might find yourself escaping it twice; one for the command itself, and other for the scripting
@this so, having the inner join dbo.NormalizeSizes(@bucketsIssued) issued on f641.id = issued.SourceRowId isn't helping at all, because the returned table has no index. However... if I first select dbo.NormalizeSizes (the TVF) into a @table with a primary key constraint, ...it all completes within 5 seconds.
declare @orderedBuckets table (
SourceRowId int not null
,SizeIndex int not null
,Units int not null
,primary key (SourceRowId,SizeIndex) -- where the magic happens (50 minutes vs 5 seconds)
);
insert into @orderedBuckets
select * from dbo.NormalizeSizes(@bucketsOrdered, 6);
TVFs cannot have any statistics so joins will inevitably suck. @variable can have statistics but only for primary keys and unique, IIRC. #variable has the full enchilada.
had to adjust my function a bit, because the buckets are sometimes 4 chars wide in a 80-char column ....and other times 6 chars wide in a 120-char column :)
I've heard reports but never tried myself --- this requires a #table; insert into it without index then create index after the fact. Some claim it's faster that way but I have my doubts that's true.
Otherwise, I don't think you can get any faster unless you make it a memory-optimized table.
@Hosch250 nah, I have a bunch of left joins where I'd normally want an inner join, so that I can log source rows that break a number of data quality and integrity rules.
I've used HeidiSQL at home and connected just fine to a mariaDB instance running in a Docker on my linux server. According to the download page, "Using Wine, it mostly runs fine on Linux and MacOS". :)
gah, query was including rows from 2011 ...cutting off the data at Fiscal 2014 (that's already more than what's actually needed) removes the bad data and fixes the PK violations. must be missing an index though, it's up to 3:30 and still processing
VBA Rubberducking
VBA Rubberducking