@Hosch250 I'd definitely ask for PayPal. An international transfer will cost you about $20, and there's no guarantee that you'll ever see the item. PayPal is free (for you) and you should get some protection should the item fail to arrive.
True, the bank transfer will cost you, but you can get it for $5. They are probably not even aware that there are costs for you. Inside the EU, bank transfers are free of charge.
I'm surprised to hear there are fee. Even from France to Québec I only paid the change rate (which was in favor of the bank of course, but not by much)
This might be a stupid question, so I apologize in advance. I am very new to VBA and coding in general.
And THANK YOU! For taking your time to help me out.
I want to create the following script:
I have two separate sheets in Excel. One containing data with corresponding parameters (which shou...
This particular debate has gone on a bit too long...
Duplicates dichotomy: [excel-vba] vs [excel] + [vba]
Tag editor extraordinaire
User on tag-edit spree for 2+ days... [excel]+[vba]=[excel-vba]
Synonymize / rename [excel-vba] and others to [excel-automation] / [excel-activex] / [excel-objects...
On a related theme Excel vba versus Access vba etc . It's the same language isn't it. And basically the same syntax. Just different methods and properties and classes... Or am I horribly misguided? #Crisis of Faith
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3956?src=pr&el=h1) Report > Merging [#3956](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3956?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/b20482c9979f3d0b123900ff3c9dceb154ddda45?src=pr&el=desc) will **increase** coverage by `0.1%`. > The diff coverage is `45.89%`.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3956?src=pr&el=h1) Report > Merging [#3956](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3956?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/b20482c9979f3d0b123900ff3c9dceb154ddda45?src=pr&el=desc) will **increase** coverage by `0.1%`. > The diff coverage is `45.89%`.
> As anyone who knows vba will tell you, there are immense differences in syntax between word-vba, excel-vba, powerpoint-vba, and outlook-vba - before answering any questions, you have to know what parent program they're writing from!
No, the difference isn't syntactic yet that's what they tend to think.
yes and it'd be even better because before, you'd be missing any questions that had excel-vba and would have had to do a 2nd search to cover the questions tagged with excel-vba but not with excel and vba. Now you only need to search excel, vba and you'll get them all
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3956?src=pr&el=h1) Report > Merging [#3956](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3956?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/b20482c9979f3d0b123900ff3c9dceb154ddda45?src=pr&el=desc) will **increase** coverage by `0.05%`. > The diff coverage is `53.55%`.
he's saying that if we accept the proposed change to change all existing questions' excel-vba tags into the excel, vba, you still can search for all questions that way.
the way things are right now.... you must do 2 searches
one for excel-vba and another for excel, vba because some people might have tagged their question using latter tags and others with former tag.
the proposal is to replace the excel-vba with excel and vba so that there is now only one way to codify such questions, and therefore, search for those questions.
equivalently, [vba] -[excel] searches for all questions tagged VBA, and not excel. You can also ignore tags to have the VBA feed only show questions related to i.e. VBA in Excel (assuming they're properly tagged of course)
from what I understood from that poster, you can't set up your favorite tag to be exclusivelyexcel and vba; it'll be a union of all questions with either tags.
and that's a big problem for VBA-tagged questions, IMO. Most users are going to be interested in one or other host and only want those highlighted, I'd think?
IMO that's a user problem. If you can follow vba, then you can answer - or at least suffer to see, the vbaexcel and vbaword questions. Chances are, the Word-hosted VBA question is about some global variable or some array construct or loop syntax error, and Word is irrelevant and anyone that can answer a VBA question should get to see it.
IMO if you can answer a VBA question, then it doesn't matter what the host application is. If you're writing "PowerPoint-VBA" and tag it as such when you have a question about how VBA the language works, i.e. you're having a problem with some part of the loop syntax or arrays or whatever, then your question will be getting fewer eyeballs just because it's not tagged with "Excel-VBA", yet 100% of the "Excel-VBA" crowd would be qualified to answer that "PowerPoint-VBA" question. The host/libs only matter if the question is about that. — Mathieu Guindon51 secs ago
I guess my fear is just around I don't know the Word object model so questions for VBA Word that I could help with would be things like control structures. Less specific to the application.
OTOH, if you learn more about other OMs, the better you get at your own OM.
IME, I've consistently found that answering a question that's tangent to my interest, gets me learning more about my interests than what I'd have if I stayed within my domain.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4127?src=pr&el=h1) Report > Merging [#4127](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4127?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/b20482c9979f3d0b123900ff3c9dceb154ddda45?src=pr&el=desc) will **increase** coverage by `0.17%`. > The diff coverage is `92.25%`.
> A specialist is one who knows more and more about less and less until the specialist knows everything about nothing. A generalist is one who knows less and less about more and more until the generalist knows nothing about everything.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4127?src=pr&el=h1) Report > Merging [#4127](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4127?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/b20482c9979f3d0b123900ff3c9dceb154ddda45?src=pr&el=desc) will **increase** coverage by `0.17%`. > The diff coverage is `92.25%`.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4127?src=pr&el=h1) Report > Merging [#4127](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4127?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/b20482c9979f3d0b123900ff3c9dceb154ddda45?src=pr&el=desc) will **increase** coverage by `0.14%`. > The diff coverage is `92.54%`.
for example, several controls must implement IOle*** interfaces but you won't see it in one of its hierarch(ies). I imagine same thing would happen w/ IControl interface.
so if you can do in VBA something like Dim c As MSForms.Control : Set c = Me.MyTextbox, assuming it's a UF with a MSForms.Textbox control, then you can cast.
I'm sure it'll work because microsoft implements IControl methods, but there is no interop for office 2000/2002 AFAIK -- at least I've never gotten it to work for office 2000, 2002, and 2010.
FWIW, I'm trying to generate a hash based on the UserForm's properties and properties of all controls in order to determine if the form actually changed to prevent an unnecessary frx from being exported.
@MathieuGuindon thinking about it, I think I overstated the impact --- it'd only break if the programmer is careless to not disambiguate the object types.
idk if a ordinary vb6 programmer will use 2-part naming. I do not see that very often from those who do VBA.
,[IsActive]=SWACTV
from [SERVER].[DB].[dbo].[ARCUS]
where (@includeInactive is null) or (@includeInactive = 0 and SWACTV=1)
ok this is driving me nuts rn
@includeInactive is a new parameter I'm adding that needs to default to null and a null value needs to not break the current behavior, which is to select all accounts regardless of their SWACTV value
the above works for null and 0, but 1 yields no records
but the pattern WHERE (@x IS NULL) OR (c = @x) is the typical design pattern for making an optional parameter that allows you to select all or a specific subset.
caveat: this pattern only works as long the column c is non-nullable.
if you need to support filtering on null for a column then it becomes: WHERE (@shouldBeFiltered = 0) OR (column = @filterValue), with 2 separate parameters.
Anyway, there is never anything preventing you from applying some indirection to translate from the needs of the calling code to the parameters of a sensibly written stored procedure.
it gets annoying, to raise flags, scream at the top of your lungs that something isn't going to work, explain why it's not going to work, and then they still go through with it, and then 8 months down the line it hits them and they're like, oh, let's reverse that
VBA Rubberducking
VBA Rubberducking