No announcement yet. "cannot read property <PROPERTY> of undefined"

  • Filter
  • Time
  • Show
Clear All
new posts "cannot read property <PROPERTY> of undefined"

    Consider this Deck.NET example:

    When calling a static, generic method located in another class, we have the option to use using static to avoid having to name the class, and we have the option to omit the generic type argument if the compiler can infer it.

    When doing either of these things (or both of them), Bridge passes the type using<TYPE> rather than just <TYPE>. I honestly have no idea what this means, since I am not aware of the internals of Bridge itself, but this causes a problem when the type does not exist on

    In my case, when using Retyped.electron, I pass the Retyped.electron.Electron.BrowserWindow type to a function like this, and when using Retyped.electron, there is not a member as is expected by the generated code, which causes the error:
    Cannot read property 'BrowserWindow' of undefined

    To see this in action, you can:
    1. Download and extract the official Bridge Electron Sample:
    2. Run yarn install and then yarn start inside of the dist folder to make sure the app is running correctly
    3. Then, close the app and open the dist/App.js file
    4. Navigate to the CreateSplashScreen function and a line of code console.log(Object.keys(; right before return splash;
    5. Run the app again using yarn start
    6. In the console, you will see that does not contain an Electron key

    For now, I will workaround this issue by explicitly naming the generic argument and class name when calling these functions with Retyped types, but it would be nice to know if this is a bug or something that I am doing wrong in my own code when it comes to using Retyped.

    Hello, your introduction here seems to support my thought about using using static instead of just using.

    For your steps to reproduce the issue, directly editing a Bridge built file is not going to keep the sanity the compiler does in the code built, so the way you suggest to reproduce the issue is not really something that Bridge can support (as it can simply have no control over it).

    Maybe if you rebuild the widgetoko project actually using the BrowsrWindow reference, you'll get working code you can base in (and understand what really does happen when you want to use it).

    Hope this helps!
    Last edited by geoffrey.mcgill; 2020-10-21 @ 12:46 PM.


      I agree that editing the JS is not a great way to reproduce the issue.

      I have created an issue on GitHub with a minimal reproduction sample showing the issue in full:

      Hopefully we can get to the bottom of it.

      Thanks for spending time to look into this issue :)