C# Discussion Boards - CodeProject

Re: "interface hack" to make private nested class instances available to outer class methods ?

12-May-22 0:19

I'm not sure I follow. Are you saying you want to prevent the user from creating new types that implement the interface outside of your assembly?

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

BillWoodruff12-May-22 1:12

Re: "interface hack" to make private nested class instances available to outer class methods ?

12-May-22 1:12

Richard Deeming wrote:
prevent the user from creating new types that implement the interface outside of your assembly?

That is a very logical next step, but this example is limited to only preventing use of the OuterClass' collections,

In this example, the end user is free to create as many Dogs and Cats as they can afford Smile | :)

p.s. the code gets more interesting when you define an encapsulated instantiator like this:

// in OuterClass1
internal T NewInstance<T>(params object[] args)
    where T : class, ISomething1
{
    var ttype = typeof(T);

    ISomething1 instance = null;

    instance = (T) Activator.CreateInstance(ttype, args);

    Somethings.Add(instance);

    return (T) instance;
}

Which is, of course, only one way to handle instantiation; I tend to avoid 'Activator.CreateInstance for reasons I am sure you are aware of.

Returning to the "big picture:" what strategies do you use to increase the encapsulation of classes that maintain collections of mixed types ?

cheers, Bill

«The mind is not a vessel to be filled but a fire to be kindled» Plutarch

Richard Deeming12-May-22 2:18

Re: "interface hack" to make private nested class instances available to outer class methods ?

12-May-22 2:18

I'm still not entire sure what you're trying to achieve.

If a generic collection contains mixed types, those types must either inherit from a base class, or implement an interface. If the collection class is public, then trying to further restrict the types it can contain to those in the current assembly, or an approved list of assemblies, is usually a sign of a broken design.

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

BillWoodruff12-May-22 2:32

Re: "interface hack" to make private nested class instances available to outer class methods ?

12-May-22 2:32

Thanks !

Richard Deeming wrote:
If the collection class is public, then trying to further restrict the type ...

In this case, the 'OuterClass is public; the whole point of this (encapsulation) is allowing access to the internal collections inside that outer class only by methods I expose.

I think you are reading into this some broader issue.

Richard Deeming wrote:
... to those in the current assembly, or an approved list of assemblies, is usually a sign of a broken design.

I can easily imagine a scenario where a design of an outer class with private internal classes would be very useful. But, that is not relevant here.

cheers, Bill

«The mind is not a vessel to be filled but a fire to be kindled» Plutarch

Richard MacCutchan11-May-22 3:19

Richard MacCutchan

11-May-22 3:19

I'd be more impressed if that code actually compiled. But even then I don't really understand what point you are trying to demonstrate.

Re: "interface hack" to make private nested class instances available to outer class methods ?

BillWoodruff11-May-22 3:50

Re: "interface hack" to make private nested class instances available to outer class methods ?

11-May-22 3:50

Thanks, added the missing 'GetSomething method, and verified it compiles/runs as expected..

Re "point:" please see response to Griff; if there is anyone on the planet I think would instantly see the "point," and be aware of the issue ... and blow my mind with a better technique ...I would pick: you OMG | :OMG:

«The mind is not a vessel to be filled but a fire to be kindled» Plutarch

harold aptroot11-May-22 10:28

harold aptroot

11-May-22 10:28

If the trick is intended to center around being able to return instances of a private class (which otherwise results in the dreaded "inconsistent accessibility" error) in an at least someone useful way (you can always return it as object, but then what?), then that's known .. by me at least, but I guess in general. The code doesn't really show that in action though. I wouldn't rate that an evil trick, more like "limited usefulness".

Otherwise if it's supposed to be a different trick then I didn't get it.

Re: "interface hack" to make private nested class instances available to outer class methods ?

BillWoodruff11-May-22 17:34

Re: "interface hack" to make private nested class instances available to outer class methods ?

11-May-22 17:34

Hi Harold, you got it. Thanks !

harold aptroot wrote:
intended to center around being able to return instances of a private class (which otherwise results in the dreaded "inconsistent accessibility" error)

"Generally known" ? My guess is it is not generally known ... took me quite an effort to locate any discussion of it.

harold aptroot wrote:
The code doesn't really show that in action though.

I would argue it does show that, in the use of the Add/Get-Something methods.

"Limited" ? Yes, the example shown here is a bare-bones demo of a technique for encapsulation ... of declared 'private inner classes, and of internal collections of instances of those classes,

I asked for opinions about its use because:

1) it's very unusual in my experience

2) it uses Interface in a very different way than usual.

3) it "feels" awkward to me.

«The mind is not a vessel to be filled but a fire to be kindled» Plutarch

BillWoodruff12-May-22 1:14

Toast notification Collections crash when initializing.

12-May-22 1:14

@Harold

the code gets more interesting when you define an encapsulated instantiator like this:

// in OuterClass1
internal T NewInstance<T>(params object[] args)
    where T : class, ISomething1
{
    var ttype = typeof(T);

    ISomething1 instance = null;

    instance = (T) Activator.CreateInstance(ttype, args);

    Somethings.Add(instance);

    return (T) instance;
}

«The mind is not a vessel to be filled but a fire to be kindled» Plutarch

Maximilien9-May-22 3:12

Re: Toast notification Collections crash when initializing.

9-May-22 3:12

I'm trying to setup a a ToastNotification collection for our toast notifications (which are working, we can create the notifications.)

I'm following this example : Toast Collections - Windows apps | Microsoft Docs

The collection is needed to set a custom name to the notification collections; it usually takes the assembly name. (which can be done but it's a hack)

The method is called after creating the main window.

The defaultManager has a member "User=null"; I'm not sure if it is a valid value for a Default Manager ?

It crashes when getting the GetToastCollectionManager :

System.Exception
  HResult=0x80070490
  Message=Element not found. (0x80070490)
  Source=<Cannot evaluate the exception source>
  StackTrace:
<Cannot evaluate the exception stack trace>

  This exception was originally thrown at this call stack:
    WpfApp1.MainWindow.CreateToastCollection() in MainWindow.xaml.cs
    WpfApp1.MainWindow.MainWindow() in MainWindow.xaml.cs

Any ideas ?

        private async void SetNotificationCollections()
        {
            string displayName = "Is Potato";
            string launchArg = "NavigateToPotato";
            System.Uri iconURI = new System.Uri("ms-appx:///Assets/icon.png");

<pre>
        ToastCollection licensingManagerToastCollection = new ToastCollection(
            "MyToastCollection",
            displayName,
            launchArg,
            iconURI);

        ToastNotificationManagerForUser defaultManager = ToastNotificationManager.GetDefault();

        try
        {
            ToastCollectionManager collectionManager = defaultManager.GetToastCollectionManager(); //CRASH/exception here.
            await collectionManager.SaveToastCollectionAsync(licensingManagerToastCollection);
        }
        catch
        {
            return;
        }
    }</pre>

CI/CD = Continuous Impediment/Continuous Despair

modified 9-May-22 9:32am.

Gerry Schmitz9-May-22 8:26

Gerry Schmitz

9-May-22 8:26

I don't think calling async methods from a constructor, particularly the main one, is a good idea; like skipping while running.

Try the "Loaded" event instead ("window ready for interaction").

Or try a button event (initially) so you have more control overall.

"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I

Re: Toast notification Collections crash when initializing.

Maximilien10-May-22 2:12

Re: Toast notification Collections crash when initializing.

10-May-22 2:12

Even if I run non-async, I still crash at the line :

ToastCollectionManager collectionManager = defaultManager.GetToastCollectionManager();

CI/CD = Continuous Impediment/Continuous Despair

Gerry Schmitz10-May-22 7:36

Gerry Schmitz

10-May-22 7:36

And you're still calling it from the constructor?

Re: Toast notification Collections crash when initializing.

Maximilien10-May-22 7:59

Re: Toast notification Collections crash when initializing.

10-May-22 7:59

no, from a button on my form.

CI/CD = Continuous Impediment/Continuous Despair

Gerry Schmitz10-May-22 9:30

Gerry Schmitz

10-May-22 9:30

Here's the constructor you're calling:

public ToastCollection( string collectionId, string displayName, string launchArgs, Uri iconUri ) {

   ApiInformation.TryRaiseNotImplemented( 
      "Windows.UI.Notifications.ToastCollection", 
     "ToastCollection.ToastCollection(string collectionId, string displayName, string launchArgs, Uri iconUri)" );
}

Seems perhaps you need to provide your own implementation of said collection.

Re: Toast notification Collections crash when initializing.

Maximilien11-May-22 2:43

Re: Toast notification Collections crash when initializing.

11-May-22 2:43

As stated, AFAIK, the crash/exception is not in the collection constructor, it's when calling :

ToastNotificationManagerForUser defaultManager = ToastNotificationManager.GetDefault();
ToastCollectionManager collectionManager = defaultManager.GetToastCollectionManager(); // crash here

CI/CD = Continuous Impediment/Continuous Despair

Sayyid Sadik12-Dec-22 4:35

Sayyid Sadik

12-Dec-22 4:35

Any solution for this?

Re: Toast notification Collections crash when initializing.

Maximilien12-Dec-22 4:46

Re: Toast notification Collections crash when initializing.

12-Dec-22 4:46

Nope, we decided that it was not worth the effort to make it work.

Maybe we'll look at it in the future.

CI/CD = Continuous Impediment/Continuous Despair

Richard Deeming9-May-22 22:00

Avoid async void methods | You’ve Been Haacked[^]

9-May-22 22:00

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

Re: Toast notification Collections crash when initializing.

Maximilien10-May-22 2:12

Access of simple activex component with only one method created in .net (using vb.net/c#) from child object created using window.open causes Catastrophic failure.

10-May-22 2:12

see other answer above,

I still crash.

CI/CD = Continuous Impediment/Continuous Despair

Satheesh N9-May-22 2:13

Satheesh N

9-May-22 2:13

Parent page:-

<object id="CtxMgr" classid="CLSID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx">

function DoCheck() {
alert(CtxMgr.InitCM());
}
function NewWindow() {
window.open('ChildWindow.html', "", "width=500,height=400");
}
var CtxMgr = document.getElementById('CtxMgr');

Child page:-

function DoCheck() {
try
{
var parentPageObj = window.opener.document.getElementById('CtxMgr');
alert(parentPageObj.InitCM());
}
catch(e) {
debugger;
}
}

Can you provide the solution for the above issue please?

Re: Access of simple activex component with only one method created in .net (using vb.net/c#) from child object created using window.open causes Catastrophic failure.

Richard Deeming9-May-22 2:34