Rather, the parser coordinator should cache all the Com** objects from TypeLib once, early in the process. That's what Max's PR did (though you need to enable the constant)
it does not use any special ctor for the ComProject but I am wondering that this might be necessary to signal to the ComProject that it's a VBA project and therefore, it needs to do additional querying from the TypeLib API to fill in the extra data.
we wouldn't want it to try and invoke TypeLib API on a non-VBA project ComProject.
public static readonly ConcurrentDictionary<Guid, ComType> KnownTypes = new ConcurrentDictionary<Guid, ComType>();
public static readonly ConcurrentDictionary<Guid, ComEnumeration> KnownEnumerations = new ConcurrentDictionary<Guid, ComEnumeration>();
public static readonly ConcurrentDictionary<Guid, ComAlias> KnownAliases = new ConcurrentDictionary<Guid, ComAlias>();
also, this "unlikely" feels much less certain if user projects are involved:
//Note - Enums and Types should enumerate *last*. That will prevent a duplicate module in the unlikely(?)
//instance where the TypeLib defines a module named "Enums" or "Types".
oh, it crashed
NotImplementedException
...and "NotImplementedException" is nowhere to be found in Rubberduck.VBEditor.VBA... wth
> Okay. I understand you all. The //todo would definitely resolve this thing. Will wait for the future. :-) Is there any way to, as @daFreeMan mentioned, disable SCP for debug.print line? Or to disable "some types of autocomplete"? If I'm not mistaken (maybe I am :-)), in the past, there were more options in Autocomplete Settings.
@M.Doerner yeah, saw that, and it works. The part I'm stuck at is getting it to collect not just the public interface, but also any fields and even more importantly, events. I'll give it another shot tonight. And then it's a matter of combining these with the parser-obtained declarations. Or does that "just work"?
@Duga Actually that presumes we can cleanly separate between the obvious cases and not-so obvious cases. IDK if that is reasonable/feasible.
@MathieuGuindon If you're going to collect everything there is to know about it, you probably need more than a copy'n'paste of the TKIND_INTERFACE case.
@MathieuGuindon for reference - that should be doable since he says it's available already. We just can't see the Implements'd interfaces, but I think we aren't there yet so.
I know what is happening there. The original " is on the new line, the "Pair Completions" completes the "Hi there" text. But I don't suppose it's wanted?
Right, hence the need to somehow merge the declarations that we derive from Com** with additional metadata from the resolver for the given declaration, no?
That is no different from VS; put in nonsense and you get nonsense formatting (which is also annoying since you have to undo the nonsensical formatting due to fat fingering)
In my SSIS ForEach Loop I have it truncate a table, then call the data flow to load the CSV to the temp table. That load step is failing (reasons yet undetermined - nope just figured it out!), updating the Result variable and updating my load table.
^all as expected.
However, it is not continuing to loop through the rest of the records in the result set that it should be processing.
Do I need to adjust the MaximumErrorCount property for the ForEach to allow it to continue? I wouldn't think so, because it's not really erroring there - the error is in the data flow and that seems to be returning and execution continues, it's just not looping.
Without the erroring files, it does run to completion as expected.
@FreeMan the maximum error count isn't the one you want if you want to basically keep processing
I think you need to have an error handler for your foreach that basically says to continue on iterating (and maybe move the bad file to some folder for you to research later)
the error handler also should log all the error data, so you know why it's there in first place, too.
there should be plenty of info from various SSIS blogs
@MathieuGuindon Ok. I was surprised that it'd do that there - it's not particularly smart with autocompleting the parentheses.
@KySoto internally, AC/SCP uses a CodeString class to encapsulate a logical line of code and the caret position; then there's a TestCodeString that extends it and is able to work with | literally representing the caret position in the code - which is great for the unit tests.
e.g.:
[Test]
public void PlacesCaretBetweenOpeningAndClosingChars_PreservesPosition()
{
var pair = new SelfClosingPair('(', ')');
var input = pair.OpeningChar;
var original = "foo = |".ToCodeString();
var expected = "foo = (|)".ToCodeString();
Assert.IsTrue(Run(pair, original, input, out var result));
Assert.AreEqual(expected, result);
}
@KySoto also, you may or may not know about this SCP feature yet:
[Test]
public void DeletingOpeningCharRemovesPairedClosingChar_Parens()
{
var pair = new SelfClosingPair('(', ')');
var input = Keys.Back;
var original = @"foo = (|2 + 2)".ToCodeString();
var expected = @"foo = |2 + 2".ToCodeString();
Assert.IsTrue(Run(pair, original, input, out var result));
Assert.AreEqual(expected, result);
}
assuming legal code, it should work with nested parentheses, and line-continuated expressions too
(a lightweight parser is getting involved for this)
@this thanks. Found this that suggests a combination of MaximumErrorCount = 0 and setting ForceExecutionResult = Success. That gets me a clean run.
I've got a table that I'm looping to determine what needs to be processed. It's also got some columns capturing results, including what step (if any failed). At the moment, at least, that's going to be my best shot at figuring out what went wrong, so I'm not really worried about handling errors w/in SSIS.
I'll report based on the table so I'll know if something failed, and the result column will tell me where it failed, so I'll start sleuthing from there.
I haven't gotten into the details of the 2nd half of that article yet. I need to get this sucker working so I can get data loaded & reports run for last month.
what i hate the most is that often when they're all "hurry and release that shitty crappy code right YESTERDAY!", then when it's over, they're all "meh, don't bother fixing. It's fine as it is."
Now I've got to tweak what was a perfectly good package to handle 3 nearly identical input types. Not sure if I want to try to load format 1, if failure, try format 2, if failure try format 3; put a flag in my driver file identifying which format; rely on file name differences to identify; build a whole new package to handle each of the other types...
Probably just a flag in the driver file would make the most sense.
@MathieuGuindon - Ahhhh... That's great! Anyways, it feels a lot better knowing what VBA Rubberducking means. Thanks for helping me out there! I'll visit this chat often, seems interesting. For now, have a good day :)