ahh, was thinking it did a literal Export of the module, which would be a .bas
had nothing in the past 10 mintues in that folder, so nothing appears to be related to that (the %temp% folder; saw nothing at all in the RD folder within)
@this in digging through the available subfolders, i have a few that look like registry-Key names, where they contian .dll and .dll.mui files ; i think mat just resolved that question, so that's something
That's why I said [citation needed] - I didn't remember off the cuff how we were handling the temp files. I have another process in my project (not RD) where I do use a temporary folder so that when I'm done, I just sink that folder, done.
/// <summary>
/// Exports the component to the folder. The file name matches the component name and file extension is based on the component's type.
/// </summary>
/// <param name="folder">Destination folder for the resulting source file.</param>
/// <param name="tempFile">True if a unique temp file name should be generated. WARNING: filenames generated with this flag are not persisted.</param>
/// <param name="specialCaseDocumentModules">If reimport of a document file is required later, it has to receive special treatment.</param>
LOL, no. More like it thrives on hiding crucial attributes from the source code, making rewriting a painful endeavor. The only way to get the source code with attributes is to export it then import it.
@Mast basically we ExportAsSourceFile for two reasons: first is if the user asked for it, second is if the parsing engine asked for it. If it's the parser exporting code files, we don't care about the filename, and we only need the file so we can parse the attributes in it and then delete it (it's not getting imported back)... so Path.GetRandomFileName is perfect here.
Pretty nice feeling to see previously Red tests go green then all that's left are the ones I've marked "Not Implemented" (Assert.Inconclusive)... and there's only three... LOL
just finished fixing that module that was giving me crap... compiled and had a bug in one of the modules... apparently the one that was "removed" earlier was still there and renamed to the name of the refactored term and wasn't visible until I compiled? not sure what in the world happened there
``` 2020-02-20 10:59:28.1631;TRACE-2.5.0.5338;Rubberduck.Common.LogLevelHelper; Rubberduck version 2.5.0.5338 loading: Operating System: Microsoft Windows NT 6.1.7601 Service Pack 1 x64 Host Product: Microsoft Office x64 Host Version: 16.0.12430.20264 Host Executable: EXCEL.EXE; 2020-02-20 11:00:11.0691;WARN-2.5.0.5338;Rubberduck.Parsing.VBA.ReferenceManagement.CompilationPasses.TypeAnnotationPass;Failed to resolve type VBE; 2020-02-
Couple of items to make note of first:
I inherited this code
I am still working through naming cells that I feel need to be named.
This code below was re-factored once with help from @TinMan on This Post
All of the code below works and I dont have any real performance issues w...
@Mast it wouldn't necessarily be just one file. It could be several files, and there could be multiple projects with same module names, etc. etc.
If one wanted to avoid the random name, I think one would need to create a folder, %temp\{$ProjectId} then stuff the files using module names in that folder.
IDK, it's a temp file, and we don't need to care about the file name... not seeing what's wrong with using the framework to generate a filename for us when we don't care what the file name is going to be
To address the specific point about logging - it shouldn't be hard to log that a random file name was created for {ProjectId}:{ProjectName}.{ModuleName}
> You can specify that a procedure parameter is optional and no argument has to be supplied for it when the procedure is called. Optional parameters are indicated by the Optional keyword in the procedure definition.
> Optional arguments are preceded by the Optional keyword in the procedure definition. You can also specify a default value for the optional argument in the procedure definition. For example:
using the Fakes API will setup hooks during test execution, hijacking internal VBA functions. You can specify per-invocation return values for functions, and then Verify whether each invocation was made with the specified parameter values
(above is just an example, you wouldn't normally invoke the faked method in the test itself)
note: a call to Verify is an assertion that can make the test fail
if you have something that you write a custom security scheme for (or actually go and implement your own flavor of an existing one), then you probably have at least some kind of threat model
Heya @IvenBach did you see my pull request comments on your two oldest PRs?
Couple of items to make note of first:
I inherited this code
I am still working through naming cells that I feel need to be named.
This code below was re-factored once with help from @TinMan on This Post
All of the code below works and I dont have any real performance issues w...
VBA Rubberducking
VBA Rubberducking