and that is where knowledge of your not-very-educational geography becomes useful, too. E.g. send certain people you dislike to a certain town in Austria.
Back to more SFW topics... When setting up an ODBC connection string, are any of the elements quoted or otherwise delimited? i.e. UID="myusername";PWD="mypassword" vs UID=myusername;PWD=mypassword
Note that requires you to use ODBC 17 or OLEDB 18.
SQLNCLI11 has no clue what Authentication is for
That's the other fun thing about the connection string. If you pass in a meaningless key-value pair, it won't throw you an error (by specification, it's not supposed to).
i am attempting to make a class to support a repeated block on a worksheet, and where I loop down my sheet from block to block, i want that iterator captured, as it tells me what line of the block to reference
currently i loop similar to:
for i = msStart to msEnd Step msStep
dst.cells(i,1).value = src.cells(i,1).value
if instr(src,"v2018") then
dst.cells(i,2).value = src.cells(i+2,2).value)
else
dst.cells(i,2).value = src.cells(i+1,2).value)
end if
next i
thinking i can create a v2018 class and get the info defined in the class
src and dst (source and destination) will be the workbooks I am pulling from, with checkboxes for each sheetname (different versions of a similar book), whereas the userform will have the user pick each from currently open workbooks and check whcih sheets to use
@Hosch250 Read your IoC example. Based on what I read you're explaining that the correct way to test and inject dependencies shouldn't break when you change from one implementation to another. If it does that's a sign of the implementation showing though.
not necessarily. constructors are implementation details, by definition. so, new set of dependencies == broken test setup, unless your test setup is using an IoC container to wire things up by convention.
actually DI works fine with optionals, it's just that the language support in C# for optional arguments makes it a royal pain in the butt for DI Containers
IIUC optional arguments are basically compiled down to overloadings
and different ctor overloads and DI don't go well together
@IvenBach <uninformedArmchairCompilerDesigner>I don't expect overloads to compile into one method. If anything, the lower you go, the more methods you see. </uninformedArmchairCompilerDesigner>
@this :shoos-away-lower-level-details: get get. Away with you details. Away. I know there are methods that are called. What's beneath them is a solid foundation certainly not made of lower level details.
@IvenBach the Create function is a factory method. When it's off a stateless default instance as I've shown, it's basically a static factory method. The purpose of that method is to perform the dependency injection, because VBA doesn't have ctors and can't do ctor injection, so instead we do property injection via a parameterized factory method.
The ugly thing about that is it's precisely the area that's most sensitive to changes.
Need a new factory method or change something about a class/interface? Chances are it that it's the factory method that get creamed in the process and you have to fix it.
even if VBA can't have IoC, the next best thing is to have a means of auto-generating the factory classes/modules.
The items that are about to be newed up also have their required arguments checked and newed up. This process continues down the chain of newing up references.
Inversion of Control / Dependency Inversion ("D" of "SOLID") is the architectural pattern that's needed for DI to be even possible. Dependency Injection is just the name given to the several different ways a dependency can end up being provided to an object/method
> Oh, I need to Resolve<IApplication>. looks at IoC config... ok, so I'm giving you an Application object, but wait... it has constructor arguments. looks at constructor arguments ...ok, so I need to Resolve<ISomething> and then I need toResolve<IFoo> so I can pass Something and Foo (again, as per IoC config), and then I can pass that to the Application constructor. But wait! Something has a parameterized constructor! ...
other than that, reflection is just like LINQ in that it's a bunch of methods in a namespace, but to inspect .NET objects rather than querying collections
@Vogel612 but if you're dealing with objects that could be newed in any arbitrary manner, you still have to resolve the constructor arguments and reflect on them all. I don't know if that can be done with reflection alone.
So to answer @jcrizk's question -- I see IoC as simply a way to make DI easier to use by handling the newing up for you whereas DI is just a convention of how you will initialize the objects with the state you want.
AFAIU, ninject actually went the other way then most c# IoC containers. It emits expression trees and let's the runtime execute them in order to create the objects.
@M.Doerner How interesting. I'm a bit surprised it came out slower since I understood that once you build the expression tree, you can compile it for faster execution.
Anyway to circle back, because RD knows so much about VBA it has the potential to help generate the DI code to make it a bit less painful to use DI in VBA.
I assumed that if all you want to know is whether there's any non-test annotations, all you want to do is annotations.Any(x => (!x is ITestAnnotation))
Why do you want to use ListView? You need to consider that as an ActiveX control it is very problematic to use due to licensing issues, limited to 32-bit, sensitive to versioning and few more problems. Maybe you should try and state what you are trying to do and we can suggest a solution that doesn't require an obsolete ActiveX control. — this14 secs ago
there's a reason why several Access developers avoid ActiveX anything
VBA Rubberducking
VBA Rubberducking