Can someone clarify if this is a bug or by design?

If I attempt to call a .NET class method marked private, InvokeMethod() can successfully call it anyway.

public class SomeClass
{
        private string IAmPrivate(string privateMsg)
        {
            return $"Your message from IAmPrivate is: {privateMsg}";
        }
}

This call from VFP works surprisingly:

lcResults = THIS.oBridge.InvokeMethod(THIS.oTest,"IAmPrivate",m.tcString)

Why?

Also, I don't necessarily mind in most cases since I'd know to not call the private method, but in overloaded method cases, this can cause issues as I've found out, since it includes the private method and returns an OLE ambiguous error since it can't determine which method you want. Well I want the public one, not the private one, duh! 😃

Any feedback appreciated Thanks.

It's by design. I have the InvokeMethod (and also property bits) set to allow access to any visibility.

Now that I think about it it's probably not a good idea and something that should probably be changed. I can't recall exactly why I did this at the time - mainly to make it possible to call private methods if necessary (which unfortunately I've found necessary on more than a few occasions since NetFX hides a lot of behavior that should be exposed).

But... given the scenario you mention (which also is probably very, very uncommon) as a possible trip up, plus the fact that the use case 99.9% public methods I think it's a good idea to switch this. Especially if you really need to call a private method you can create a .NET component and do it from there with private Reflection.

I think this affects a lot of code - All the Invoke, Set/Get methods of various stripes...

+++ Rick ---

Thanks for the clarification Rick.

In the interest of not breaking everyone's existing code or handling the rare cases you mentioned, perhaps you can introduce some way to allow for a developer to actively designate they want to filter out all non-public access.

Not sure which way you prefer to do that, either by new parameters to existing funcs, new funcs altogether or some global setting on the bridge itself, but which ever way you go I'm sure we'd appreciate it.

Thanks.

Honestly I don't think anybody wanted to use private access - if it happened it was by accident which is pretty unlikely.

Adding logic to deterministically set this is just too confusing I think and if we did to make sense the current behavior would have to persist by default, which is not a great idea IMHO.

I'll make the change and it'll be in the next update.

+++ Rick ---

Sounds good, thanks for all your work on this amazing tool.

Here's an updated version that has the change:

https://west-wind.com/files/WebConnectionExperimental.zip

+++ Rick ---

Checked it out and it seems to be working properly to ignore privates now, thanks Rick.