VBA Rubberducking - 2018-11-21 (page 3 of 3)

« first day (1629 days earlier) ← previous day next day → last day (1551 days later) »

6:00 PM

PLCs aren't made for regulation tuning. DCSs are

I only have brief scholastic experience with them.

PLCs are made for fast processes, mostly digital ones, like robotics

DCSs are made for large scale system with slow variations

A PLC will usually have a cycle time of a few milliseconds, even microseconds. A DCS has a cycle time between 1 and 10s depending on what you monitor (Each device has its scan rate)

A temperature, for example, will move slowly, so it will usually be updated once ever 5 seconds or so

The time differential between the two answers it.

The size of what you control also does. I have rarely seen PLCs with more than a few dozen IOs. The controllers we currently use manage up to 1000 I/Os

Late to the party again.

6:04 PM

@M.Doerner how could you possibly be late to a party that's been going nonstop for 4 years?

Regarding Access complaining at 2GB of RAM used, I do not exctly know the reason, but I think it has rather clear historical reasons why it is 2GB if it is any value.

And regarding non-progammers using Access to hack together spplications, I am one of those users, just a rather unusual one.

I can only agree that Access is a wonderful tool for that.

In particular, because it allows you to automate stuff without having IT involved.

Btw, I am not too sure the GC actually realizes that there is this strange limit of 2GB in Access.

IIR, doesn't Excel have a similar limit?

I am not sure; I have never managed to push Excel to such memory usage.

Yep, it does.

> 32-bit environment is subject to 2 gigabytes (GB) of virtual address space, shared by Excel, the workbook, and add-ins that run in the same process. A data model’s share of the address space might run up to 500 – 700 megabytes (MB), but could be less if other data models and add-ins are loaded.

> Excel 2016 offers the Large Address Aware functionality that lets 32-bit Excel 2016 consume twice the memory when users work on a 64-bit Windows operating system. For more information, see Large Address Aware capability change for Excel.

This is rather stupid, in particular when running on a 64-bit system.

6:10 PM

Gee, thanks Excel 2016 for allowing me to fill my address space.

hmm, link, @Comintern ?

support.office.com/en-us/article/…

thanks!

the LAA thing is news to me

On old 32-bit systems there really was a hard limit of 2GB.

The other halve of the available address space was system memory.

Right. Although wasn't that configurable through the registry?

6:12 PM

However, on a 64-bit system, there is really no need to restrain the memory size of a 32-bit application.

Been a long time since I've run 32bit Windows.

I think, starting with XP, you could yield one additional GB to the user.

yeah, LAA would offer that option, too

I once read the chapter about it in Reymond Chen's book.

but it says it's not automatically enabled for that scenario, though

whereas 64-bit OS + 32- bit Excel would have LAA enabled automatically.

which makes sense.

(is there any good reason to run 32-bit OS today?)

6:14 PM

It could actually yield the full 4GB, if it wanted.

System memory lives in an entirely different block now anyway.

Unless you have really old hardware, there is no reason.

Considering that typically such hardware that are expensive & difficult to replace will usually communicate over wires or something, the problem is almost moot.

It'd have to be hardware that directly interfaces with the PC via motherboard bus, I guess.

6:29 PM

I'm thinking that if I have this:

  Exit Function

ErrHandle:

End Function

at the end of my function, that's not properly "exiting error recovery" and I really need something like this:

CleanExit:
  Exit Function

ErrHandle:
  Resume CleanExit
End Function

because VBA needs the Resume keyword to properly close out the On Error Goto ... statement.

Is that correct?

generally, yes

it's better if your procedures has only one entry and one exit

this becomes more important when you have objects in the procedure that need to be cleaned up (e.g. closing a file handle for example or resetting the mouse cursor from hourglass)

On the cleanup side of things, yes, I agree 100%. I was wondering about the "resetting" (for lack of a better word) of the error handling. IIRC, VBA will just abort if I have a 2nd error after that first block of code because it will treat it as an error within the error handler because it never hit a Resume.

you still should reset the error handler, yes.

Wait, doesn't the error handler lose it's context when you exit the function though?

thx. That's what I thought...

waiting...

6:39 PM

There shouldn't be any reason to explicitly Resume.

not always the case

it ought to but there are cases where the error state do not reset, in particular with OERN

Hm, shouldn't you clear the Err object?

This is mainly defensive coding.

Resume or Exit both will clear the Err object.

Ah, OK.

Or hitting the End Sub at the bottom.

6:41 PM

^ not always true.

Huh? Give me an example.

Public Sub Derp()
    Duh
    Debug.Print Err.Number
End Sub

Public Sub Duh()
    On Error Resume Next
    Debug.Print 1 / 0
End Sub

Starts a new argument over semantics. Pops popcorn

Right, I was referring to this case:

Public Sub Derp()
    Duh
    Debug.Print Err.Number
End Sub

Public Sub Duh()
    On Error GoTo Handler
    Debug.Print 1 / 0
Handler:
End Sub

OERN basically disables the error handler in general.

The hitting End Sub is explicit in the language spec:

> An <on-error-statement> specifies a new error-handling policy for the current activation of the containing procedure.

Yet OERN makes this a lie... The point is as i said earlier, defensive coding.

6:47 PM

That's referring to the context in which it actually throws.

I.e., above, it wouldn't jump to the error handler in Derp if it wasn't cleared.

The OERN lie is this:

> Continue execution within the same procedure activation with the <statement> that in normal execution order would be executed immediately after the <statement> whose execution caused the error to be raised.

I think.

here's my problem, though. Take out the OERN, and you get that 4 button dialog

put it back in, and put in an error handler in the Derp procedure, and it won't even know about hte error

Actually, I was wrong. This is the lie:

> The Err object is reset.

^ That's explicitly the spec for any Resume statement.

@this The issue there isn't that Err.Clear isn't called, it's that your error handling isn't scoped correctly.

yet, the behavior of OERN is very different from a normal error handler

with OERN, one must consistently add the OEG0

or provide some similar guard

we also haven't discussed about what should happen when an error happens inside an error handler.

because the rules is different in that context, too.

Why do you need to guard though? If you have in-line error handling, that should be reset immediately before the call that can throw.

Public Sub Derp()
    Duh
    On Error Resume Next
    Debug.Print Err.Number
End Sub

Public Sub Duh()
    On Error Resume Next
    Debug.Print 1 / 0
End Sub

7:03 PM

that's not Derp's job...

Duh should clean up its darned mess....

No, it's not Derp's concern if a called function ignores an error.

Coding as if it is intermingles the concerns of who is handling or ignoring which errors.

Nope but Duh shouldn't be altering the state like that...

Huh? It should be concerned about it's own state, and nothing else.

but it spilled the Err state over into the Derp

If you're coding inline error handling, you can't assume that the Err object has any given state.

It's similar to GetLastApiError in that regard.

7:06 PM

that's altering the state in my book.

It's only useful immediately after an API call.

except, the Err object doesn't present itself like that.

you do have an explicit method call with the GetLastDllError

but you get an Err object.

Seeing if (toggleButton1.Checked == true) in an example on MSDN just feels wrong...

Inline error handling is the same thing. The call just comes before the error test, not after.

thus, it feels really wrong to me that Derp could leave Err in that state when it ends for Duh to stumble over.

7:08 PM

If Duh is checking the state of the Err object without it's own OERN call, that's a coding error in Duh.

What? you're saying callers are responsible for cleaning a shitty API's mess?

Yes.

I reject that.

API should clean up its darned mess.

Why should any procedure make state assumptions after calling an external procedure?

it's not my concern to know that there was an error. Just don't hand me a bogus error.

7:10 PM

If you check the Err object on some random line of code, you get what you deserve.

in VBA, the Err is a part of the state, so it's a Bad Thing™ to leave it unaltered.

Except it isn't altering state that matters. Err.Number is the last error, period. Same as GetLastDllError.

If you're making the assumption that is any specific error with intervening code, you're Doing It Wrong™.

This code shows that the error state and error handling in Duh is reset at the exit of the Sub.

Public Sub Derp()
    Duh
    Debug.Print Err.Number
    On Error GoTo Handler
    Debug.Print 1 / 0
Handler:
  Debug.Print Err.Number
End Sub

Public Sub Duh()
    On Error GoTo Handler
    Debug.Print 1 / 0
Handler:
End Sub

Also, boys - play nice!

@Comintern here's the thing. WE have to read the Err.Number inside the error handler.

If it has to call a function as part of the error handling (say to log a error) and it has an OERN

by time the function returns and the original error handler continues, the Err is now messed up.

for that reason, it is necessary to make a copy of Err object if your error handler calls a external function and ensuring that it cleans itself up.... lot of manual work for what?

If C#'s try had the similar cute behavior, I would reasonably think there'd be lot of angry developers.

Pardon. I made a mistake. I said "Err object". I forgot the scare quotes around the "object".

Definitely needs scare quotes.

Except it isn't "cute behavior". If you're using a global, you shouldn't ever make state assumptions. Ever.

Public Sub Example()
    On Error Resume Next
    SomeSub
    SomeOtherSub
    If Err.Number <> 0 Then
        'This was a test that never should have been made.
    End If
End Sub

7:27 PM

in the end of day, error shouldn't be a state.

No argument there.

nonetheless VB* designers screwed the pooch there

so we must deal with the consequences.

in fact, I'd assert that this illustrates how we have so much cargo cult code in VB* family.

Right, but you're more irresponsible not to do that as the caller.

Well, in fairness, if you don't want a cargo cult, stop dropping supplies from airplanes.

in my mind, the API has bigger burden to keep things sane. The caller knows nothing about the internals and should not care.

LOL

1 hour later…

8:43 PM

[rubberduck-vba/Battleship] web-flow pushed commit 346f27d2 to master: Update README.md

9:02 PM

> Come up with a generic solution and apply it to your specific problem.

Must be some of the best advice I got regarding programming.

9:26 PM

@Comintern Is my understanding correct that the com collector generates all declarations with the QMN of the project?

More or less, yes. It can omit some forward declared types.

That was rather a surprise to me.

I was already questioning our clean up logic for unloading references.

Actually, I take that back. We don't generate declarations for IUnknown or IDispatch.

I'd need to check to see how other restricted interfaces are handled.

My surprise was that they all have the same QMN.

I was expecting to have one QMN per component.

The rationale for that is certainly ancient. When I went over it, I stuck with the current behavior.

I'm not exactly sure if anything breaks if that is fixed. Same thing with everything being scoped to global.

9:31 PM

This gives me yet another thing I have to consider for the cache invalidation.

If it makes cache invalidation easier if the QMNs are "real", I'd go ahead and do it. Sooner or later that should be fixed.

There might be a handful of inspections that use the current behavior, but I can't imagine it would have much impact unless they're used more heavily in the resolver than I'm aware.

Just so I'm following - didn't we want all declarations to have a QMN in order to be able to resolve its type fully?

Happy Birthday to me. I forget about it any more.

That's evidence of my senility, needing people to remind me about my own birthday. Bad omen of what's to come.

Congratulations on yet another successful revolution around the sun, @IvenBach!

3

Thanks.

Besides avoiding the buses and pineapples, I'm not doing much to aid in that revolution.

I hope to still be around this pond next year too.

9:38 PM

@IvenBach Actually, your mass contributes to the Earth's net gravitational attraction to the Sun, just like everyone else's.

It contributed to the pull before I was born, and will still continue long after I'm gone.

It's just happens to be "momentarily" mine. A tad more than I'd like BTW.

Not planning on leaving the planet then?

Well, traveling at 1,000 MPH for some million miles is pretty impressive.

Wish I could.

I like the fact that I'm traveling fastest at night.

@this This is why you should never ask "relative to what" when presented with a speeding ticket.

9:45 PM

You'd think being charged with enforcing the laws they'd have some appreciation for proper science.

"Oh yeah, smart-ass? Here's a ticket for 1070 in a 55."

IDK if htere's any jurisdictions in US that does it but AIUI, in Finland, the fines are levied based on how fast you were going; the faster you go, the much higher it is.

Probably be a few cool millions, give or take.

Personally, I think it should be a combination of speed and mass.

Going 20 over in a tractor trailer is much more dangerous than in a sub-compact.

Granted, but that seems to favor the sports bikes unfairly, doesn't it?

e.g. they can go 100 over and get fined the same as a SUV going 10 over

True, but Darwinism doesn't exactly favor them.

9:49 PM

Yeah. they're called "organ donors" for a reason.

news.bbc.co.uk/2/hi/europe/1759791.stm

Nokia speeding ticket.

yeah i actually was thinking of that incident. But seems that I misremembered the detail - fines are based on income, not on speed.

There needs to be a lower limit in fines. Otherwise WalMart employees can drive 200 mph in a school zone and only be fined 23cents.

What?

Someone making $5/hr would pay minimal fines vs someone making $50/hr or more.

9:56 PM

Someone making $5/hr probably couldn't afford gas in Finland.

^

Mathieu Guindon

@Comintern well technically, that mass was already on Earth well before @IvenBach showed up, so...

happy birthday @IvenBach!

Thanks.

True, but that doesn't undermine Iven's claim that his mass is just as helpful as anyone else's.

Is my birthday gift the ability to build RD? 'Cause that sure would be swell.

10:10 PM

I thought you could build now. Or was that just at home?

Only at home.

Still errors out at work.

Mathieu Guindon

makes a good reason to actually work :)

shhhh (my boss might hear you)

@IvenBach I had similar build woes the other day. Some combination of "upgrade VS", "clear NuGet cache" and "clean then rebuild" solved it for me. Not sure which one was key.

@IvenBach And we're talking about next, with a clean clone?

10:14 PM

@Comintern Yep

did you try clearing your nuget cache yet?

Mathieu Guindon

I haven't worked on RD at work (not counting cowboy commits on GH web UI) since RD needs VS2017 to build

@mansellan How do I go about doing that?

^

Mathieu Guindon

TTGH

10:15 PM

tools -> nuget package manager options

or similar, on the train atm

Package manager console?

below that i think

launches VS

Package Manager Settings

mkay

You should be able to just delete the folder manually too.

NuGet cache(s) clear failed at 11/21/2018 2:17:21 PM.
Error: Clearing local resources failed: Unable to delete one or more files.
Please see https://aka.ms/troubleshoot_nuget_cache for more help.

10:18 PM

wait wut?

hmm, try manually - go to C:\users\{you} and delete the .nuget folder

Try deleting everything from %userprofile%\.nuget\packages in windows explorer.

(assuming you haven't moved it)

Just deleted file. Was Antlr folder with a single DLL.

fun fact - if you're on a domain that one folder alone can cause your login to take many many minutes

mine was like 6gb, all coming down at login time

Another fun fact, that folder should have had more than just a single dll.

10:20 PM

:shudder:

^^

I cleared it before I went into it.

ah yes

Oh wait - it might have partially cleared before the error.

That was likely the single offending folder that wasn't working.

10:20 PM

ok cool

now clean

then rebuild

I'd clean -> build instead of rebuild.

oh?

Yeah, I haven't had much luck with rebuild.

Granted, I've never tried it after a clean.

Habit I guess.

Hrm. Clean adds directories back.

Wait, wut?

Clean pulls packages?

10:22 PM

hmm, would expect (re)build to do that

Opening RD caused 33 directories to be built.

but whatever, it's whenever Nuget feels like restoring them

OK, that's probably a good sign.

the point is though that it won't have all the old crud in there, just what RD currently needs

Either way I cleaned, shut VS down, deleted .nuget/packages/ contents and am building.

10:23 PM

crosses fingers

Oh sweet. Happy birthday to me. Build Failure.

Still the same errors.

Happy Birthday! @IvenBach

1>------ Build started: Project: RubberduckCodeAnalysis, Configuration: Release Any CPU ------
1>C:\Users\cpaustell\source\repos\Rubberduck\RubberduckBaseProject.csproj : warning MSB4011: "C:\Users\cpaustell\.nuget\packages\sunburst.net.sdk.wpf\1.0.47\Sdk\Sdk.props" cannot be imported again. It was already imported at "C:\Users\cpaustell\source\repos\Rubberduck\RubberduckCodeAnalysis\RubberduckCodeAnalysis.csproj". This is most likely a build authoring error. This subsequent import will be ignored.

@IvenBach bah

At least there's consistency.

10:26 PM

thats just a warning

need the first actual error

oh wait

expand comment

Clean again, then build again.

I really need to finish up on cleaning the build warnings up.

Same result after another Clean then Build.

does C:\Users\cpaustell\source\repos\Rubberduck\Rubberduck.Core\obj\Debug\net46\Rubbe‌rduck.Core.dll exist?

No. Those DLLs don't get created.

hmm - anything at all under ...\Ruberduck.Core\obj?

10:31 PM

Yes.

Cashe, Jon, Project Property, and Targets files.

Along with the Debug directory.

and anything in \debug or \debug\net46?

11 files and UI directory.

4 CACHE files, 1 Text file, 6 .cs files.

odd... all the errors from that project are for xaml

just a thought...

go to your RD folder in Windows Explorer

close VS

search for all bin folders, delete them

then same for obj

then try to build again

(VS clean sometimes, uh, doesn't)

Tried that previously with same result. I'll try again.

oh ok

10:37 PM

I shoulda made a PS script to do this.

to me it looks like something is preventing the XAML files from being turned into auto-magic c# files

i.e. something wrong with your VS tooling

no idea what though

For belts-n-suspenders safety I also cleaned and deleted all nuget packages folders.

cool

if this don't work I'm officially Outta Ideas...

Learned that from a more knowledgeable duck than I.

Same errors.

bah

10:43 PM

Thanks for the help with clearing the packages. Learned how to do that.

think you might end up having to reinstall VS at some point...

:-(

Already tried that.

oh...

uh

Twice. For good measure.

May just need a new tower...
:Inches screwdriver towards PSU:

wow. it's really broken...

10:50 PM

Yep.

Forcing myself to convert my Excel VBA add-ins into VSTO add-ins to still be using work time efficiently.

I think I will need some help with my current PR:

2018-11-21 23:37:20.7198;ERROR-2.2.6899.42483;Rubberduck.Parsing.VBA.ParseCoordinator;Unexpected exception thrown in parsing run. (thread 8).;System.AggregateException: One or more errors occurred. ---> System.NotImplementedException: Didn't expect a TYPEATTR with multiple typekind flags set in H:\Benutzer\Döner\Eigene Dokumente\Rubberduck\Testing\Test7.xlsm.
   at Rubberduck.Parsing.ComReflection.ComProject.LoadModules(ITypeLib typeLibrary) in N:\Repositories\Rubberduck\Rubberduck.Parsing\ComReflection\ComProject.cs:line 159

Hm, after merging next, I can no longer build.

what is the error w/ the build fro next?

RE: the TYPEKIND -- what is the value you're getting?

18>------ Build started: Project: Rubberduck.Deployment, Configuration: Debug Any CPU ------
18>N:\Repositories\Rubberduck\RubberduckBaseProject.csproj : warning MSB4011: "C:\Users\Dörner\.nuget\packages\sunburst.net.sdk.wpf\1.0.47\Sdk\Sdk.props" cannot be imported again. It was already imported at "N:\Repositories\Rubberduck\Rubberduck.Deployment\Rubberduck.Deployment.csproj". This is most likely a build authoring error. This subsequent import will be ignored.
18>N:\Repositories\Rubberduck\Rubberduck.Deployment\Rubberduck.Deployment.csproj : warning MSB4011: "C:\Users\Dörner\.nuget\package…

I have no idea how the ComProject works.

this looks like the build is failing because Excel is locking up the files

it might be ghosted.

verify that Excel is truly dead before you try to build.

I would set a breakpoint in the debugger, if I could build.

Oh, that error message is not helpful.

And you are right.

10:58 PM

I know. the Error List is almost useless now.

The strange thing is that it can build Main although that is loaded in Excel.

no, that should not be the case

all the registrations should point to the assets within the Deployment.

It told me that it built 18 and one failed; I had a failed message for Deployment.

Oh, but isn't the entry point in Main?

yes it is but note that the output of Main gets copied into Deployment

Oh, I see. I never studied the script.

11:02 PM

similarly, the API gets copied into the Deployment. This way, the registration scripts only has to work with only one folder

Incidentally, that's why Deployment (among with the test project) is the last project to build.

Too bad Iven's problems is not as simple as that.

That bugs the snot out of me.

code analysis on the test project is really taking some time.

i've come to take to building only the Deployment rather than the solution

But even so, if I've made some changes, there are lot of projects that must be re-built.

I tend to do a clean and build and test run before I push.

11:19 PM

Regarding the TYPEKIND, I get TKIND_MAX, i.e. the end of enumeration marker, for the type for ThisWorkbook.

What?

I don't know whether that is due to how Wayne implemented the TypeLibWrapper or because the internal typelib contains interesting data.

Hm, I will try in Access, whether I also get that for ordinary modules.

Just reminded me. Wayne added one more enum for vba

It was not documented too

Tkind_vba or something like that

github.com/rubberduck-vba/Rubberduck/blob/…

OK, Access fails even harder.

Indeed vba has an extra enum member

what happened w access

11:26 PM

hard crash on parse

attaching VS to Access is taking ages

since the vba and max overlaps you will need verify if it is vba

I have to say that it is really inconvenient that the exception dialog only shows the bottom part of the stack trace.

What does TKIND_VBACLASS represent? Is that the user classes and document extensions?

11:43 PM

Undocumented. Aiui, any kind of vba components including standard modules

dont think documents count

Use addin object in vbe to see how it works

TKIND_VBACLASS has the same value as TKIND_MAX.

However, I am not sure what to do in this case.

26 mins ago, by this

since the vba and max overlaps you will need verify if it is vba

I'd start with using the same case as TKIND_COCLASS and see what you get.

I think wayne put in a method to test if is a vba class in tje typelib api

I'm not exactly sure from Wayne's comment if .bas modules get the same type-kind.

11:56 PM

hence my suggestion to use the addin object

TKIND_MAX should never show up in a COM library if my read of the documentation is correct.

agree but worried other clowns may have had same idea to overload that value

I think they don't.

Why would they? Non-standard COM signatures aren't really going to much for the random developer.

ahem and who authored vba?...

11:58 PM

In Access, I did not get the not implmented exception whith only standard modules.

Even if they did, I'm not sure running them through TKIND_COCLASS would do much more than skip things like enums, etc.

It hit an assert.

Which assert?

I could not see it; the stack trace was too long.

« first day (1629 days earlier) ← previous day next day → last day (1551 days later) »

Transcript for

Nov '1821

VBA Rubberducking

This chat has moved to Discord: discord.gg/MYX9RECenJ

antlr com-interop parsing rubberduck vb6 vba whiskey-tango-foxtrot

join this room
about this room

00:00

06:00

12:00

18:00

all times are UTC

site design / logo © 2024 Stack Exchange Inc; legal

mobile