Cool_Tools/ExplorerPatcher
1
0
Fork 0
mirror of https://github.com/valinet/ExplorerPatcher.git synced 2024-11-24 07:30:22 +01:00
Code Releases Wiki Activity
bfca879e68
ExplorerPatcher/ep_weather_host/ep_weather_host.h

307 lines
17 KiB
C
Raw Normal View History

Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
#ifndef _H_AS_SERVICE_P_H_
#define _H_AS_SERVICE_P_H_
#include "ep_weather.h"
#include "ep_weather_utility.h"
Work on ARM64 shell extension support
2024-07-13 15:50:37 +02:00
#include "ep_weather_host_h.h"
Weather: Rearchitected component lifetime
2022-02-17 22:42:13 +01:00
#include "../ExplorerPatcher/def.h"
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
#include <windowsx.h>
#include <ShlObj.h>
#include <Shobjidl.h>
#include <dwmapi.h>
#pragma comment(lib, "Dwmapi.lib")
#include <netlistmgr.h>
#include <Iphlpapi.h>
#pragma comment(lib, "IPHLPAPI.lib")
#include "WebView2.h"
Fixes for weather panel, implemented icon-less modes, implemented dynamic size to fit contents
2022-01-27 22:03:02 +01:00
#pragma comment(lib, "uxtheme.lib")
Weather widget adjusts its size vertically to accommodate the entire contents
2022-01-30 02:26:19 +01:00
#include <ShellScalingApi.h>
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
#include <shlwapi.h>
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
DEFINE_GUID(IID_ITaskbarList,
0x56FDF342, 0xFD6D, 0x11d0, 0x95, 0x8A, 0x00, 0x60, 0x97, 0xC9, 0xA0, 0x90);
Weather: Widget properly respects text size accessibility setting
2022-02-17 01:48:17 +01:00
#define EP_WEATHER_NUM_SIGNALS 4
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
#define EP_WEATHER_TIMER_REQUEST_REPAINT 1
#define EP_WEATHER_TIMER_REQUEST_REPAINT_DELAY 1000
Weather: Widget supports dark mode (thanks @krlvm) (#755)
2022-01-31 01:30:34 +01:00
#define EP_WEATHER_TIMER_REQUEST_REFRESH 10
#define EP_WEATHER_TIMER_REQUEST_REFRESH_DELAY 2000
Weather: Refactored browser rebound procedure
2022-02-06 19:11:57 +01:00
#define EP_WEATHER_TIMER_SCHEDULE_REFRESH 11
Weather: Widget properly respects text size accessibility setting
2022-02-17 01:48:17 +01:00
#define EP_WEATHER_TIMER_RESIZE_WINDOW 15
#define EP_WEATHER_TIMER_RESIZE_WINDOW_DELAY 150
Weather: Fixed a bug that could prevent the widget from properly loading It seems that either the web page, either something in Microsoft's WebView2 implementation changed so that when `ICoreWebView2::NavigationCompleted` is fired, the elements of interest on the page are not ready, which causes all this mess, as you can tell. The solution for now was to delay the execution of my scripts, which seemed to have gotten rid of the problem for now. I don't particularly like the solution, I'd of course want something more robust, but I guess these are the pitfalls when you do not control the entire ecosystem...
2023-03-01 19:38:35 +01:00
#define EP_WEATHER_TIMER_EXECUTEDATASCRIPT 20
#define EP_WEATHER_TIMER_EXECUTEDATASCRIPT_DELAY 500
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
typedef struct _GenericObjectWithThis GenericObjectWithThis;
/* EPWeather */
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
typedef interface EPWeather
{
CONST_VTBL IEPWeatherVtbl* lpVtbl;
unsigned int cbCount;
HRESULT hrLastError;
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/**/HANDLE hMainThread;//
/**/HANDLE hInitializeEvent;//
/*//*/HWND hWnd;//
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
INT64 bBrowserBusy; // interlocked
HWND hNotifyWnd; // interlocked
LONG64 dwTemperatureUnit; // interlocked
LONG64 dwUpdateSchedule; // interlocked
WCHAR wszTerm[MAX_PATH];
WCHAR wszLanguage[MAX_PATH];
LONG64 cbx; // interlocked
LONG64 cby; // interlocked
LONG64 dwProvider; // interlocked
Implemented weather widget error screen
2022-01-29 22:55:06 +01:00
LONG64 bIsNavigatingToError; // interlocked
Weather: Widget supports dark mode (thanks @krlvm) (#755)
2022-01-31 01:30:34 +01:00
LONG64 g_darkModeEnabled; // interlocked
LONG64 dwGeolocationMode;
Weather: Widget displays with rounded corner after logon; implemented option to change corner preference
2022-02-08 18:58:02 +01:00
LONG64 dwWindowCornerPreference;
Weather: Registry setting to toggle dev tools in the browser
2022-02-26 12:26:12 +01:00
LONG64 dwDevMode;
Weather: Fixed display issues in RTL layouts (#954)
2022-03-01 14:01:30 +01:00
LONG64 dwTextDir;
Weather: Implemented icon pack with day/night support
2022-03-06 07:00:59 +01:00
LONG64 dwIconPack;
Weather: Implemented zoom levels (#1033)
2022-03-09 19:08:03 +01:00
LONG64 dwZoomFactor;
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/**/HANDLE hMutexData;// // protects the following:
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
DWORD cbTemperature;
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/*//*/LPCWSTR wszTemperature;//
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
DWORD cbUnit;
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/*//*/LPCWSTR wszUnit;//
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
DWORD cbCondition;
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/*//*/LPCWSTR wszCondition;//
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
DWORD cbImage;
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/*//*/char* pImage;//
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
DWORD cbLocation;
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/*//*/LPCWSTR wszLocation;//
Weather: Widget properly respects text size accessibility setting
2022-02-17 01:48:17 +01:00
LONG64 dwTextScaleFactor; // interlocked
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/**/HMODULE hUxtheme;//
/**/HMODULE hShlwapi;//
/**/HKEY hKCUAccessibility;//
/**/HKEY hKLMAccessibility;//
Weather: Widget properly respects text size accessibility setting
2022-02-17 01:48:17 +01:00
DWORD cntResizeWindow;
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
RECT rcBorderThickness; // local variables:
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/*//*/ITaskbarList* pTaskList;//
/*//*/ICoreWebView2Controller* pCoreWebView2Controller;//
/*//*/ICoreWebView2* pCoreWebView2;//
/*//*/GenericObjectWithThis* pCoreWebView2NavigationStartingEventHandler;//
Weather: Show "Reload" link when data fails to load
2022-05-28 12:43:54 +02:00
EventRegistrationToken tkOnNavigationStarting;
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/*//*/GenericObjectWithThis* pCoreWebView2NavigationCompletedEventHandler;//
Weather: Fix and free event registration tokens
2022-05-28 12:41:05 +02:00
EventRegistrationToken tkOnNavigationCompleted;
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/*//*/GenericObjectWithThis* pCoreWebView2PermissionRequestedEventHandler;//
Weather: Fix and free event registration tokens
2022-05-28 12:41:05 +02:00
EventRegistrationToken tkOnPermissionRequested;
Weather widget adjusts its size vertically to accommodate the entire contents
2022-01-30 02:26:19 +01:00
RECT rc;
Weather: Implemented zoom levels (#1033)
2022-03-09 19:08:03 +01:00
LONG64 dpiXInitial;
LONG64 dpiYInitial;
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
FARPROC SHRegGetValueFromHKCUHKLMFunc;
LONG64 cbGenericObject;
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/**/HANDLE hSignalExitMainThread;//
/**/HANDLE hSignalKillSwitch;//
/**/HANDLE hSignalOnAccessibilitySettingsChangedFromHKCU;//
/**/HANDLE hSignalOnAccessibilitySettingsChangedFromHKLM;//
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
} EPWeather;
ULONG STDMETHODCALLTYPE epw_Weather_AddRef(EPWeather* _this);
ULONG STDMETHODCALLTYPE epw_Weather_Release(EPWeather* _this);
HRESULT STDMETHODCALLTYPE epw_Weather_QueryInterface(EPWeather* _this, REFIID riid, void** ppv);
HRESULT STDMETHODCALLTYPE epw_Weather_About(EPWeather* _this, HWND hWnd);
Weather: Implemented zoom levels (#1033)
2022-03-09 19:08:03 +01:00
HRESULT STDMETHODCALLTYPE epw_Weather_Initialize(EPWeather* _this, WCHAR wszName[MAX_PATH], BOOL bAllocConsole, LONG64 dwProvider, LONG64 cbx, LONG64 cby, LONG64 dwTemperatureUnit, LONG64 dwUpdateSchedule, RECT rc, LONG64 dwDarkMode, LONG64 dwGeolocationMode, HWND* hWnd, LONG64 dwZoomFactor, LONG64 dpiXInitial, LONG64 dpiYInitial);
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
HRESULT STDMETHODCALLTYPE epw_Weather_Show(EPWeather* _this);
HRESULT STDMETHODCALLTYPE epw_Weather_Hide(EPWeather* _this);
HRESULT STDMETHODCALLTYPE epw_Weather_GetWindowHandle(EPWeather* _this, HWND* phWnd);
HRESULT STDMETHODCALLTYPE epw_Weather_IsInitialized(EPWeather* _this, BOOL* bIsInitialized);
HRESULT STDMETHODCALLTYPE epw_Weather_LockData(EPWeather* _this);
HRESULT STDMETHODCALLTYPE epw_Weather_GetDataSizes(EPWeather* _this, LPDWORD pcbTemperature, LPDWORD pcbUnit, LPDWORD pcbCondition, LPDWORD pcbImage);
HRESULT STDMETHODCALLTYPE epw_Weather_GetData(EPWeather* _this, DWORD cbTemperature, LPCWSTR wszTemperature, DWORD cbUnit, LPCWSTR wszUnit, DWORD cbCondition, LPCWSTR wszCondition, DWORD cbImage, char* pImage);
HRESULT STDMETHODCALLTYPE epw_Weather_GetTitle(EPWeather* _this, DWORD cbTitle, LPCWSTR wszTitle, DWORD dwType);
HRESULT STDMETHODCALLTYPE epw_Weather_UnlockData(EPWeather* _this);
HRESULT STDMETHODCALLTYPE epw_Weather_SetNotifyWindow(EPWeather* _this, HWND hWndNotify);
HRESULT STDMETHODCALLTYPE epw_Weather_SetTemperatureUnit(EPWeather* _this, LONG64 dwTemperatureUnit);
HRESULT STDMETHODCALLTYPE epw_Weather_SetUpdateSchedule(EPWeather* _this, LONG64 dwUpdateSchedule);
HRESULT STDMETHODCALLTYPE epw_Weather_SetTerm(EPWeather* _this, DWORD cbTerm, LPCWSTR wszTerm);
HRESULT STDMETHODCALLTYPE epw_Weather_SetLanguage(EPWeather* _this, DWORD cbLanguage, LPCWSTR wszLanguage);
HRESULT STDMETHODCALLTYPE epw_Weather_SetIconSize(EPWeather* _this, LONG64 cbx, LONG64 cby);
HRESULT STDMETHODCALLTYPE epw_Weather_GetIconSize(EPWeather* _this, LONG64* cbx, LONG64* cby);
Weather: Widget supports dark mode (thanks @krlvm) (#755)
2022-01-31 01:30:34 +01:00
HRESULT STDMETHODCALLTYPE epw_Weather_SetDarkMode(EPWeather* _this, LONG64 dwDarkMode, LONG64 bRefresh);
HRESULT STDMETHODCALLTYPE epw_Weather_IsDarkMode(EPWeather* _this, LONG64 dwDarkMode, LONG64* bEnabled);
HRESULT STDMETHODCALLTYPE epw_Weather_SetGeolocationMode(EPWeather* _this, LONG64 dwGeolocationMode);
Weather: Widget displays with rounded corner after logon; implemented option to change corner preference
2022-02-08 18:58:02 +01:00
HRESULT STDMETHODCALLTYPE epw_Weather_SetWindowCornerPreference(EPWeather* _this, LONG64 dwWindowCornerPreference);
Weather: Allow widget resize and move when using dev mode
2022-02-26 23:04:37 +01:00
HRESULT STDMETHODCALLTYPE epw_Weather_SetDevMode(EPWeather* _this, LONG64 dwDevMode, LONG64 bRefresh);
Weather: Implemented icon pack with day/night support
2022-03-06 07:00:59 +01:00
HRESULT STDMETHODCALLTYPE epw_Weather_SetIconPack(EPWeather* _this, LONG64 dwIconPack, LONG64 bRefresh);
Weather: Implemented zoom levels (#1033)
2022-03-09 19:08:03 +01:00
HRESULT STDMETHODCALLTYPE epw_Weather_SetZoomFactor(EPWeather* _this, LONG64 dwZoomFactor);
Weather: Display last time of update in Properties
2022-03-14 03:53:48 +01:00
HRESULT STDMETHODCALLTYPE epw_Weather_GetLastUpdateTime(EPWeather* _this, LPSYSTEMTIME lpLastUpdateTime);
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
static const IEPWeatherVtbl IEPWeather_Vtbl = {
.QueryInterface = epw_Weather_QueryInterface,
.AddRef = epw_Weather_AddRef,
.Release = epw_Weather_Release,
.About = epw_Weather_About,
.Initialize = epw_Weather_Initialize,
.Show = epw_Weather_Show,
.Hide = epw_Weather_Hide,
.GetWindowHandle = epw_Weather_GetWindowHandle,
.LockData = epw_Weather_LockData,
.GetDataSizes = epw_Weather_GetDataSizes,
.GetData = epw_Weather_GetData,
.UnlockData = epw_Weather_UnlockData,
.SetNotifyWindow = epw_Weather_SetNotifyWindow,
.IsInitialized = epw_Weather_IsInitialized,
.GetTitle = epw_Weather_GetTitle,
.SetTemperatureUnit = epw_Weather_SetTemperatureUnit,
.SetTerm = epw_Weather_SetTerm,
.SetLanguage = epw_Weather_SetLanguage,
.SetIconSize = epw_Weather_SetIconSize,
.GetIconSize = epw_Weather_GetIconSize,
.SetUpdateSchedule = epw_Weather_SetUpdateSchedule,
Weather: Widget supports dark mode (thanks @krlvm) (#755)
2022-01-31 01:30:34 +01:00
.SetDarkMode = epw_Weather_SetDarkMode,
.SetGeolocationMode = epw_Weather_SetGeolocationMode,
Weather: Widget displays with rounded corner after logon; implemented option to change corner preference
2022-02-08 18:58:02 +01:00
.SetWindowCornerPreference = epw_Weather_SetWindowCornerPreference,
Weather: Registry setting to toggle dev tools in the browser
2022-02-26 12:26:12 +01:00
.SetDevMode = epw_Weather_SetDevMode,
Weather: Implemented icon pack with day/night support
2022-03-06 07:00:59 +01:00
.SetIconPack = epw_Weather_SetIconPack,
Weather: Implemented zoom levels (#1033)
2022-03-09 19:08:03 +01:00
.SetZoomFactor = epw_Weather_SetZoomFactor,
Weather: Display last time of update in Properties
2022-03-14 03:53:48 +01:00
.GetLastUpdateTime = epw_Weather_GetLastUpdateTime,
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
};
Weather: Widget properly respects text size accessibility setting
2022-02-17 01:48:17 +01:00
static inline DWORD epw_Weather_GetTextScaleFactor(EPWeather* _this) { return InterlockedAdd64(&_this->dwTextScaleFactor, 0); }
Weather: Implemented zoom levels (#1033)
2022-03-09 19:08:03 +01:00
static inline DWORD epw_Weather_GetZoomFactor(EPWeather* _this) { return InterlockedAdd64(&_this->dwZoomFactor, 0); }
static inline DWORD epw_Weather_GetStyle(EPWeather* _this) { SetLastError(0); return GetWindowLongW(_this->hWnd, GWL_STYLE); }
static inline DWORD epw_Weather_HasMenuBar(EPWeather* _this) { return 0; }
static inline DWORD epw_Weather_GetExtendedStyle(EPWeather* _this) { SetLastError(0); return GetWindowLongW(_this->hWnd, GWL_EXSTYLE); }
Weather: Widget properly respects text size accessibility setting
2022-02-17 01:48:17 +01:00
static void epw_Weather_SetTextScaleFactorFromRegistry(EPWeather* _this, HKEY hKey, BOOL bRefresh);
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
HRESULT STDMETHODCALLTYPE epw_Weather_static_Stub(void* _this);
ULONG STDMETHODCALLTYPE epw_Weather_static_AddRefRelease(EPWeather* _this);
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/* ICoreWebView2EnvironmentOptions */
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
HRESULT STDMETHODCALLTYPE ICoreWebView2_get_AdditionalBrowserArguments(ICoreWebView2EnvironmentOptions* _this, LPWSTR* value);
HRESULT STDMETHODCALLTYPE ICoreWebView2_get_Language(ICoreWebView2EnvironmentOptions* _this, LPWSTR* value);
HRESULT STDMETHODCALLTYPE ICoreWebView2_get_TargetCompatibleBrowserVersion(ICoreWebView2EnvironmentOptions* _this, LPWSTR* value);
HRESULT STDMETHODCALLTYPE ICoreWebView2_get_AllowSingleSignOnUsingOSPrimaryAccount(ICoreWebView2EnvironmentOptions* _this, BOOL* allow);
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
HRESULT STDMETHODCALLTYPE ICoreWebView2EnvironmentOptions_QueryInterface(IUnknown* _this, REFIID riid, void** ppv);
static const ICoreWebView2EnvironmentOptionsVtbl EPWeather_ICoreWebView2EnvironmentOptionsVtbl = {
.QueryInterface = ICoreWebView2EnvironmentOptions_QueryInterface,
.AddRef = epw_Weather_static_AddRefRelease,
.Release = epw_Weather_static_AddRefRelease,
.get_AdditionalBrowserArguments = ICoreWebView2_get_AdditionalBrowserArguments,
.put_AdditionalBrowserArguments = epw_Weather_static_Stub,
.get_Language = ICoreWebView2_get_Language,
.put_Language = epw_Weather_static_Stub,
.get_TargetCompatibleBrowserVersion = ICoreWebView2_get_TargetCompatibleBrowserVersion,
.put_TargetCompatibleBrowserVersion = epw_Weather_static_Stub,
.get_AllowSingleSignOnUsingOSPrimaryAccount = ICoreWebView2_get_AllowSingleSignOnUsingOSPrimaryAccount,
.put_AllowSingleSignOnUsingOSPrimaryAccount = epw_Weather_static_Stub,
};
static const ICoreWebView2EnvironmentOptions EPWeather_ICoreWebView2EnvironmentOptions = {
.lpVtbl = &EPWeather_ICoreWebView2EnvironmentOptionsVtbl
};
/* GenericObjectWithThis */
typedef struct _GenericObjectWithThis {
IUnknownVtbl* lpVtbl;
void* pInstance;
LONG64 cbCount;
EPWeather* _this;
LPWSTR pName;
} GenericObjectWithThis;
GenericObjectWithThis* GenericObjectWithThis_MakeAndInitialize(IUnknownVtbl* vtbl, EPWeather* _this, const LPWSTR pName);
ULONG STDMETHODCALLTYPE GenericObjectWithThis_AddRef(GenericObjectWithThis* _this);
ULONG STDMETHODCALLTYPE GenericObjectWithThis_Release(GenericObjectWithThis* _this);
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
Weather: Widget supports dark mode (thanks @krlvm) (#755)
2022-01-31 01:30:34 +01:00
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/* INetworkListManagerEvents */
HRESULT STDMETHODCALLTYPE INetworkListManagerEvents_QueryInterface(GenericObjectWithThis* _this, REFIID riid, void** ppv);
HRESULT STDMETHODCALLTYPE INetworkListManagerEvents_ConnectivityChanged(GenericObjectWithThis* _this2, NLM_CONNECTIVITY newConnectivity);
static const INetworkListManagerEventsVtbl INetworkListManagerEvents_Vtbl = {
.QueryInterface = INetworkListManagerEvents_QueryInterface,
.AddRef = GenericObjectWithThis_AddRef,
.Release = GenericObjectWithThis_Release,
.ConnectivityChanged = INetworkListManagerEvents_ConnectivityChanged,
};
/* */
Weather: Widget supports dark mode (thanks @krlvm) (#755)
2022-01-31 01:30:34 +01:00
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/* ICoreWebView2CreateCoreWebView2EnvironmentCompletedHandler */
HRESULT STDMETHODCALLTYPE ICoreWebView2CreateCoreWebView2EnvironmentCompletedHandler_QueryInterface(GenericObjectWithThis* _this, REFIID riid, void** ppv);
HRESULT STDMETHODCALLTYPE ICoreWebView2_CreateCoreWebView2EnvironmentCompleted(GenericObjectWithThis* _this, HRESULT errorCode, ICoreWebView2Environment* pCoreWebView2Environment);
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
static const ICoreWebView2CreateCoreWebView2EnvironmentCompletedHandlerVtbl EPWeather_ICoreWebView2CreateCoreWebView2EnvironmentCompletedHandlerVtbl = {
Weather: Fixed a bug that prevented the widget from working when WebView2 Runtime >= 102.0.1245.33
2022-06-07 18:35:41 +02:00
.QueryInterface = ICoreWebView2CreateCoreWebView2EnvironmentCompletedHandler_QueryInterface,
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
.AddRef = GenericObjectWithThis_AddRef,
.Release = GenericObjectWithThis_Release,
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
.Invoke = ICoreWebView2_CreateCoreWebView2EnvironmentCompleted,
};
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/* */
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/* ICoreWebView2CreateCoreWebView2ControllerCompletedHandler */
HRESULT STDMETHODCALLTYPE ICoreWebView2CreateCoreWebView2ControllerCompletedHandler_QueryInterface(GenericObjectWithThis* _this, REFIID riid, void** ppv);
HRESULT STDMETHODCALLTYPE ICoreWebView2_CreateCoreWebView2ControllerCompleted(GenericObjectWithThis* _this, HRESULT hr, ICoreWebView2Controller* pCoreWebView2Controller);
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
static const ICoreWebView2CreateCoreWebView2ControllerCompletedHandlerVtbl EPWeather_ICoreWebView2CreateCoreWebView2ControllerCompletedHandlerVtbl = {
Weather: Fixed a bug that prevented the widget from working when WebView2 Runtime >= 102.0.1245.33
2022-06-07 18:35:41 +02:00
.QueryInterface = ICoreWebView2CreateCoreWebView2ControllerCompletedHandler_QueryInterface,
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
.AddRef = GenericObjectWithThis_AddRef,
.Release = GenericObjectWithThis_Release,
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
.Invoke = ICoreWebView2_CreateCoreWebView2ControllerCompleted,
};
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/* */
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/* ICoreWebView2NavigationStartingEventHandler */
HRESULT STDMETHODCALLTYPE ICoreWebView2NavigationStartingEventHandler_QueryInterface(GenericObjectWithThis* _this, REFIID riid, void** ppv);
HRESULT STDMETHODCALLTYPE ICoreWebView2_NavigationStarting(GenericObjectWithThis* _this, ICoreWebView2* pCoreWebView2, ICoreWebView2NavigationStartingEventArgs* pCoreWebView2NavigationStartingEventArgs);
Weather: Show "Reload" link when data fails to load
2022-05-28 12:43:54 +02:00
static const ICoreWebView2NavigationStartingEventHandlerVtbl EPWeather_ICoreWebView2NavigationStartingEventHandlerVtbl = {
Weather: Fixed a bug that prevented the widget from working when WebView2 Runtime >= 102.0.1245.33
2022-06-07 18:35:41 +02:00
.QueryInterface = ICoreWebView2NavigationStartingEventHandler_QueryInterface,
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
.AddRef = GenericObjectWithThis_AddRef,
.Release = GenericObjectWithThis_Release,
Weather: Show "Reload" link when data fails to load
2022-05-28 12:43:54 +02:00
.Invoke = ICoreWebView2_NavigationStarting,
};
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/* ICoreWebView2NavigationCompletedEventHandler */
HRESULT STDMETHODCALLTYPE ICoreWebView2NavigationCompletedEventHandler_QueryInterface(GenericObjectWithThis* _this, REFIID riid, void** ppv);
HRESULT STDMETHODCALLTYPE ICoreWebView2_NavigationCompleted(GenericObjectWithThis* _this, ICoreWebView2* pCoreWebView2, ICoreWebView2NavigationCompletedEventArgs* pCoreWebView2NavigationCompletedEventArgs);
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
static const ICoreWebView2NavigationCompletedEventHandlerVtbl EPWeather_ICoreWebView2NavigationCompletedEventHandlerVtbl = {
Weather: Fixed a bug that prevented the widget from working when WebView2 Runtime >= 102.0.1245.33
2022-06-07 18:35:41 +02:00
.QueryInterface = ICoreWebView2NavigationCompletedEventHandler_QueryInterface,
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
.AddRef = GenericObjectWithThis_AddRef,
.Release = GenericObjectWithThis_Release,
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
.Invoke = ICoreWebView2_NavigationCompleted,
};
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/* ICoreWebView2PermissionRequestedEventHandler */
HRESULT STDMETHODCALLTYPE ICoreWebView2PermissionRequestedEventHandler_QueryInterface(GenericObjectWithThis* _this, REFIID riid, void** ppv);
HRESULT STDMETHODCALLTYPE ICoreWebView2_PermissionRequested(GenericObjectWithThis* _this, ICoreWebView2* pCoreWebView2, ICoreWebView2PermissionRequestedEventArgs* pCoreWebView2PermissionRequestedEventArgs);
static const ICoreWebView2PermissionRequestedEventHandlerVtbl EPWeather_ICoreWebView2PermissionRequestedEventHandlerVtbl = {
.QueryInterface = ICoreWebView2PermissionRequestedEventHandler_QueryInterface,
.AddRef = GenericObjectWithThis_AddRef,
.Release = GenericObjectWithThis_Release,
.Invoke = ICoreWebView2_PermissionRequested,
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
};
Weather: Widget supports dark mode (thanks @krlvm) (#755)
2022-01-31 01:30:34 +01:00
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/* ICoreWebView2CallDevToolsProtocolMethodCompletedHandler */
HRESULT STDMETHODCALLTYPE ICoreWebView2CallDevToolsProtocolMethodCompletedHandler_QueryInterface(GenericObjectWithThis* _this, REFIID riid, void** ppv);
HRESULT STDMETHODCALLTYPE ICoreWebView2_CallDevToolsProtocolMethodCompleted(GenericObjectWithThis* _this, HRESULT errorCode, LPCWSTR returnObjectAsJson);
Weather: Widget supports dark mode (thanks @krlvm) (#755)
2022-01-31 01:30:34 +01:00
static ICoreWebView2CallDevToolsProtocolMethodCompletedHandlerVtbl EPWeather_ICoreWebView2CallDevToolsProtocolMethodCompletedHandlerVtbl = {
Weather: Fixed a bug that prevented the widget from working when WebView2 Runtime >= 102.0.1245.33
2022-06-07 18:35:41 +02:00
.QueryInterface = ICoreWebView2CallDevToolsProtocolMethodCompletedHandler_QueryInterface,
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
.AddRef = GenericObjectWithThis_AddRef,
.Release = GenericObjectWithThis_Release,
Weather: Widget supports dark mode (thanks @krlvm) (#755)
2022-01-31 01:30:34 +01:00
.Invoke = ICoreWebView2_CallDevToolsProtocolMethodCompleted
};
Weather: Fixed a bug that could hang the host process and explorer A nasty bug was sometime occurring where both explorer and the widget host process could hang; this often happened when explorer was restarted. The reason this happened was because the widget host process could hang waiting for the "Lock_EPWeather_Instance" lock. This was a global lock that made sure only one instance of the widget could be created. The idea of the global "Lock_EPWeather_Instance" lock was, of course, pretty bad, but I chose it because I couldn't figure out/didn't want to deal with passing an EPWeather "this" instance to WebView2 or NetworkListManagerEvents functions. Bad decision. This patch addresses this bug, by providing a generic object which holds a reference to EPWeather "this" on which I build event handlers for WebView2 and so on. Since these now contain this reference, they cannot be static anymore, thus I switched to dynamically allocating them and managing them throughout their lifetime using, of course, reference counting. This is the proper solution. Thus, this bug and any similar ones should now be fixed.
2022-08-05 14:31:36 +02:00
/* ICoreWebView2ExecuteScriptCompletedHandler */
HRESULT STDMETHODCALLTYPE ICoreWebView2ExecuteScriptCompletedHandler_QueryInterface(GenericObjectWithThis* _this, REFIID riid, void** ppv);
HRESULT STDMETHODCALLTYPE ICoreWebView2_ExecuteScriptCompleted(GenericObjectWithThis* _this, HRESULT hr, LPCWSTR pResultObjectAsJson);
static const ICoreWebView2ExecuteScriptCompletedHandlerVtbl EPWeather_ICoreWebView2ExecuteScriptCompletedHandlerVtbl = {
.QueryInterface = ICoreWebView2ExecuteScriptCompletedHandler_QueryInterface,
.AddRef = GenericObjectWithThis_AddRef,
.Release = GenericObjectWithThis_Release,
.Invoke = ICoreWebView2_ExecuteScriptCompleted,
Implemented weather taskbar widget
2022-01-27 03:35:27 +01:00
};
#endif
Copy Permalink