Readying a window before displaying it to users (size/position of window & content)

Issues - Platform and API
,
1

According to documentation, to open a window properly, you have to instantiate it using overwolf.windows.obtainDeclaredWindow() then use overwolf.windows.restore() to open it.
I want to scale the window & its content before presenting them, so I am instantiating it first without doing a restore. I restore it when I am done scaling.

This works only when desktop_only & native_window is set to true. It doesn’t work otherwise.

I tried to get openWindows after obtaining the windows, and it doesn’t show the window unless desktop_only & native_window is set to true. Maybe that has something to do with it, since the window isn’t being instantiated. Note that the result of obtaining a non-desktop/native window is a success.

Am I doing something wrong? Is there a way to ready the window before presenting it to the user?

2

@YasserKa hi and sorry for the delay.
Which scaling exactly are you doing? Scaling of the content? Have you tried to restore the window ID and not the window name? Can you show me some example code that I can use it to reproduce?

3

For testing purposes, I am using the sample app:

The background controller has this block of code:

  overwolf.windows.onStateChanged.addListener(async () => {
    const openWindows = await WindowsService.getOpenWindows();
    if (Object.keys(openWindows).length <= 1) {
      window.close();
    }
  });

In the manifest.json, the desktop window has the following attributes:

"native_window": true,
"desktop_only": true,

The app works fine as it is.
If you removed the mentioned attributes from the manfiest.json the app will close by itself. Why? commenting out the conditional block and adding console.log(openWindows) shows:

overwolf
overwolf1290×150 34.8 KB

The first time it’s triggered, the only open windows are background and so it will close the app.

If I put back the attributes in manifest.json, the result is similar to above without the first log that states that the background window is the sole window open.

I made another test where I commented out the overwolf.windows.restore() block
within the restore function supplied by the windows-service.js

  function restore(name) {
    return new Promise(async (resolve, reject) => {
      try {
        await obtainWindow(name);
        // overwolf.windows.restore(name, (result) => {
        //   if (result.status === 'success') {
        //     resolve();
        //   } else {
        //     reject(result);
        //   }
        // });
      } catch (e) {
        reject(e)
      }
    });
  }

The window is only obtained, so the window doesn’t appear as predicted.
Going back to the backgorund controller. The overwolf.windows.onStateChanged block mentioned earlier is triggered when the attributes are in the manifest.json showing that the open windows are background & main. On the other hand, when the attributes aren’t in the manifest.json, it’s not triggered at all.
I didn’t do any scaling or change for the window, but I believe that this might be related to the issue at hand.

4

@YasserKa, the version of the sample app that you are referring to, is the old version.
We have an updated version, that is built using TypeScript:

This is the version that also displayed in our official docs:
https://overwolf.github.io/docs/start/sample-app-overview.

First of all, please test and play with the official sample app, and then raise the questions, as I don’t want to start investigating issues that might be “obsoleted” or fixed in the new version.

If you still have more questions after that, or if you still have the same issue as described above, please also tell me what your purpose is. What are you trying to achieve, and why you can’t. That will help me to direct you to the solution.

Thanks!

Eran

5

My application is based on the obsolete version of the platform, and I don’t have time to spare to understand the newer version & make the transition.
The problem that I am facing is minor and isn’t app-breaking, so it’s not worthy to put more effort in resolving it. You can mark it as resolved if you want.
Thanks for your time Eran.

PS. It would be nice to mention that the native sample example is obsolete (not recommended) in the repo or the documentation.

6

Sure - I will add a note immediatly. Closing the issue. thanks