#TIL all of the web links in VB6 (Main Menu->Help->Microsoft on the Web) are dead. No 404, just a blank page. Only an MS favicon to hint that it's actually resolved.
Wonder if anyone at MS even notices the occasional hit on them
Looking at the source, it feels like it will be impossible to improve memory and CPU performance :c The way Declarations are handled is impossible to rewrite without breaking lots of stuff
I wish the project was far less harder to understand. I've been doing C# for a few years and it's a nightmare to understand RD :c
That's why I asked about the MT and PTL. I know just enough C# to get in myself in trouble and I know that MT is very hard. Heck, I couldn't finish the suspension action without lot of help from Max.
@this yep shouldn't be hard. the perfect solution would be to make it act just like default (i.e. a 2-item context menu attached to the window header), but that's overkill for a quick fix
public void Foo()
{
var token = new CancellationToken();
Bar(token);
token.Cancel();
token = new CancellationToken();
}
public async void Bar(CancellationToken token){}
Bar's token isn't the first one--it was reference passed, and re-assigned to the new one.
private List<CancellationToken> _tokens;
public void Foo()
{
_tokens = new List<CancellationToken>();
_tokens.Add(new CancellationToken());
Bar(_tokens.First());
_tokens.First().Cancel();
_tokens.Clear();
_tokens.Add(new CancellationToken());
}
public async void Bar(CancellationToken token){}
@this I have already done lots of multithreading, but it rarely required complex stuff. My concern is more about the code structure and less about the program flow
@FreeMan Yeah, but I wish to contribute. RD is very useful to me but all the performance issues make working with it harder and harder
When I need to export stuff from MS Access, I consitently have to close the DB, not open VBE, and do my exports. I also can't run RD on machines with less than 4 GB of RAM due to the fact it can easily reach 500-600MB of RAM (while Access alone takes only 20-30 MB)
It was, same as the "RD parses the code 4 times when exporting" stuff, exponentially increasing RAM usage because it looks like not everything gets GCd
Parsing the same code multiple times does increase RAM usage. Since the code didn't change, I'm assuming something that should get cleaned between each parsing isn't
Gah! I just realized that someone scheduled a meeting for 3-4 pm today. I was hoping to slip out of the office for an early start to my Thanksgiving weekend. Very not fun!
I'm new to vba and wrote the code below to match and copy columns; I'm trying to figure out how to make it more efficient as it takes some time to churn out the output. Any advice or feedback would be much appreciated! I thought of switching screen updating to false but it doesn't really speed th...
for a while I thought the 45K declarations and the many copies we cache in the DeclarationFinder was part of the memory problem - it isn't. declarations really are peanuts.
My currently open Excel project was sitting idle for a bit and was at 364M. A parse brought it upwards of 429M. A 2nd parse brought it to 476M, then a spike at >600M with a drop back to 445M stablish. A 3rd parse spiked to 515M, dropped to 470M then climbed to 570M where it's currently sitting. I'll let it idle a bit to see if it drops back to <400M
> If a small managed object allocates a large amount of unmanaged memory, the runtime takes into account only the managed memory, and thus underestimates the urgency of scheduling garbage collection.
there's also the notion that an IDE add-in like RD is NOT lightweight. this isn't MZ "msgbox assistant" or "toggle line numbers". we're talking in-depth, [mostly] thorough understanding of what the code is doing - reading in some R# comment section that one has a solution opened in VS consuming 400MB, consumes 2GB with R#. Insight doesn't come for free.
VBA Rubberducking
VBA Rubberducking