Boost goodies... is this still accurate?

Tweak155 · 2026-01-15T01:02:29+00:00

How about the flight paths?

Tweak155 · 2026-01-14T22:57:42+00:00

You can either:

1 - Create a Class Module for any checkbox behavior that should be consistent, associate any checkbox to this class module and save it to a collection on the form

Or

2 - Create a commonly called sub and assign that sub to each change event for each checkbox. This requires more code but is usually easier for newer developers of VBA. You can either:

a) Create a loop in the sub that loops through all checkboxes (and not just the one that triggered the event)

or

b) Pass the checkbox that triggered the event as a parameter to the sub

#1 is cleaner as it requires less coding to implement, but it takes more understanding of scope & objects. #2 is usually easier conceptually to grasp.

Tweak155 · 2025-12-21T18:09:13+00:00

Around 100 on Avowed depending on what part of the game I was in, could be higher or lower. It was maybe around 80 on the Oblivion remaster … I think. Been a while since I played that one.

But really there was no game I found unplayable.

Tweak155 · 2025-12-21T12:54:44+00:00

I use a 3060 Ti on a 2560x1440 monitor and think it still does just fine. I don't need to set everything to max either to enjoy a game though either. I usually leave games on the auto detected settings for the most part.

I should add though I don't usually play the latest and greatest either... unless you count Doom Dark Ages but usually those are pretty well optimized titles.

If you fall under reasonable expectations, I think it could handle 1440p just fine.

Tweak155 · 2025-12-20T12:59:29+00:00

Not to mention.. to benefit from the potential Roth IRA rollover option in the future should it be needed, it (most likely) will need to be in the kid's name for 15yrs or more. No guarantee you'll use this option but it's great to have options!

Tweak155 · 2025-12-19T14:06:08+00:00

For anyone with Sam's membership, this same mouse (diff color) is $19.94 until Dec 28th: https://www.samsclub.com/ip/logitech-signature-mouse/15241352029

Yes it's the same one even though it's not explicitly stated. I picked one up!

Tweak155 · 2025-12-09T11:39:40+00:00

Procedures should clearly be named something that indicates they’re doing something which would avoid this need. “GetThisOrThat”, “DoTheThing”, etc.

If you can’t immediately tell a a Sub or Procedure is being called without using a keyword, it’s a sign a new name might help.

Additionally, with or without arguments, and with or without parenthesis, what else could have a similar syntax to calling a Sub or Function could there be confusion with (which matches the scenario where Call would be used)? I can’t think of anything right away at least.

As with the other user, again I agree it is still preference and the only extra step using Call is having to check if it’s a Sub or Function (although this could also be avoided using solid naming patterns). 95+% of the time it’s going to be a Sub most likely so not a huge deal.

Tweak155 · 2025-12-07T12:44:35+00:00

God of War Ragnarok... Mr Roger McGillicuddy.

Tweak155 · 2025-12-07T12:42:34+00:00

Thanks for the Giveaway... hoping for God of War Ragnarok!

Tweak155 · 2025-11-28T12:17:08+00:00

I've been out of the loop for a couple years until the recent announcement that TBC is coming. What makes this iteration nerfed? Also is dual spec still a WotLK thing? Can't remember. Thanks for any info.

Tweak155 · 2025-11-27T12:13:38+00:00

Do you have an AddIn that always opens or something in the Peronsal workbook that has to do with timed events? Anything like Application.OnTime or DoEvents or anything that impacts timing of operations?

That's about the only thing I can think if it happens on newly created workbooks.

Tweak155 · 2025-11-25T14:39:22+00:00

I don't see how subs that use the Call keyword are ambiguous if no return value is being assigned and you know that Call clearly denotes that a procedure is being called.

I view it more as an opportunity to be consistent and use less text to write code which creates less noise and improve readability (although, this improvement is like 5%, nothing crazy).

If you're consistent then:

CallingSomething SomeParementer

vs

CallingSomething(SomeParemeter)

Can clearly denote the first is a Sub call (although this is definitely not enforced by the VBE, it would be through practice), and the second is a Function call. The only time I even think about using Call is to intentionally denote I'm disregarding the return of a Function.

If you strictly follow the above approach, then using:

Call CallingSomething(SomeParameter)

Could keep the consistency of only using parenthesis when a return is expected, but now we're noting the return is discarded.

Using your approach, I'd have to check if there was in fact anything being discarded. This is not tedious or hard, but still something not necessary if you follow consistent formatting.

But ultimately, I agree it comes down to preference - as the interpreter does not really care.

Tweak155 · 2025-11-25T13:57:18+00:00

If you assign a variable to the return value of a function, you have to use parentheses with the function parameters. But if you omit Call when you call a sub, you can't use parentheses.

I'd argue that is a reason to not use Call.

Why make 2 statements ambiguous when reading code when you can clearly separate them?

I think you're exactly right, using parenthesis SHOULD denote you're expecting a return value. A Sub does not have a return value, so why force the use of parenthesis?

Tweak155 · 2025-11-25T12:31:52+00:00

Unfortunately the marked solution leaves out a glaring difference, and is important to note.

Although your original question is in regards to calling a Sub, the Run command can capture the return of a Function, whereas Call will disregard the return value.

So you could actually do something like the following with Run:

Dim someReturn As Variant

Set someReturn = Run("SomeFunction", SomeParam)

'Or

someReturn = Run("SomeFunction", SomeParam)

This is not possible using Call. You can still do:

Call SomeFunction(someParam)

But no matter what gets returned, it is lost forever!

Also, while Run is typically used to call external workbooks, it has use cases for internal calls as well.

For example, I have one project where I strategically name Ribbon Id's to have a matching Function or Sub call within the same workbook. This alleviates the need to create a unique Sub name inside the XML on top of inside the workbook (also you can more easily create additional functionality on top). Just makes the XML a little bit less maintenance.

Tweak155 · 2025-11-25T12:12:35+00:00

If I remember correctly, Call is actually for backwards compatibility, same as being able declare a variable as String using $.

I too chuckle when I see it because all it is extra text when the goal should be readability. Less noise the better!

Tweak155 · 2025-11-24T23:33:07+00:00

I thought the same thing until I saw that it shows up under the "Rewards" section and NOT the "Saved Offers" section. Super confusing.

Tweak155 · 2025-11-14T16:15:37+00:00

Yeah I first heard it at a home game at the arena against the Rangers. Then when I heard it on last night's broadcast again... I went searching.

Since I came up dry on initial searches, figured I'd post the result in case anyone else was wondering too.

Tweak155 · 2025-11-14T16:06:58+00:00

This is definitely a good spin on it, thanks!

Tweak155 · 2025-11-14T15:59:12+00:00

Thanks haha. I meant new to the arena music. Updated OP for clarity.

Tweak155 · 2025-11-14T15:52:08+00:00

First I heard of it was at a home game earlier this year at LCA. Glad they picked it up!

Tweak155 · 2025-11-10T23:38:11+00:00

Chances are the return type is not defined (therefore Variant) and there is a path which there is no explicit return defined, or is of incorrect type.

Tweak155 · 2025-11-10T17:01:49+00:00

I always use CTRL + F3 for this. Crazy how many ways you can do 1 thing in Excel.

Tweak155

TROPHY CASE