mirror of
https://github.com/fadden/ciderpress.git
synced 2024-06-10 06:29:36 +00:00
4638d03d6c
In the past, CiderPress managed its own file associations. This is the feature that launches CiderPress when you double-click on a ".shk" file. The installer ran "CiderPress -install" and "-uninstall" during installation and removal to give CP a chance to establish and clean up the necessary registry entries. The code built with VS6 works fine. The code built with VS2013 fails with an access denied error. It appears there have been some access policy changes, and the older code is getting "grandfathered in". This is really something that the installer ought to be handling, though, so rather than figure out how to fix CiderPress, I'm removing the file type association code from CiderPress and letting DeployMaster handle it. This may be slightly less convenient for anyone who had reason to change type associations frequently. Modern versions of Windows have relatively easy to use control panel UIs for adjusting types, and the "advanced installation" feature of DeployMaster allows you to un-check the types that you don't want to have associated with CiderPress. (...with one minor hitch: DeployMaster 4.2.2 only shows the first 9 associations, and CiderPress has 18.) This change renders most of the registry-handling code obsolete, as well as the "-install" / "-uninstall" handling. I'm 99% sure I want to go this way, but I'm keeping things #ifdefed rather than deleted for the moment.
73 lines
1.7 KiB
C++
73 lines
1.7 KiB
C++
/*
|
|
* CiderPress
|
|
* Copyright (C) 2007 by faddenSoft, LLC. All Rights Reserved.
|
|
* See the file LICENSE for distribution terms.
|
|
*/
|
|
/*
|
|
* The application object.
|
|
*/
|
|
#ifndef APP_MYAPP_H
|
|
#define APP_MYAPP_H
|
|
|
|
#include "Registry.h"
|
|
|
|
/* CiderPress version numbers */
|
|
#define kAppMajorVersion 4
|
|
#define kAppMinorVersion 0
|
|
#define kAppBugVersion 0
|
|
#define kAppDevString L"d1"
|
|
|
|
/*
|
|
* Windows application object.
|
|
*/
|
|
class MyApp: public CWinApp
|
|
{
|
|
public:
|
|
MyApp(LPCTSTR lpszAppName = NULL);
|
|
virtual ~MyApp(void);
|
|
|
|
#ifdef CAN_UPDATE_FILE_ASSOC
|
|
MyRegistry fRegistry;
|
|
#endif
|
|
|
|
const WCHAR* GetExeFileName(void) const { return fExeFileName; }
|
|
const WCHAR* GetExeBaseName(void) const { return fExeBaseName; }
|
|
|
|
/*
|
|
* Handles pop-up help requests. Call this from OnHelpInfo.
|
|
*/
|
|
static BOOL HandleHelpInfo(HELPINFO* lpHelpInfo);
|
|
|
|
/*
|
|
* Handles help topic requests. Call this from OnHelp.
|
|
*/
|
|
static void HandleHelp(CWnd* pWnd, DWORD topicId);
|
|
|
|
private:
|
|
virtual BOOL InitInstance(void) override;
|
|
virtual BOOL OnIdle(LONG lCount) override;
|
|
|
|
/*
|
|
* Show where we got something from. Handy for checking DLL load locations.
|
|
*
|
|
* If "name" is NULL, we show the EXE info.
|
|
*/
|
|
void LogModuleLocation(const WCHAR* name);
|
|
|
|
/*
|
|
* This holds pairs of control IDs and popup help IDs, for use by
|
|
* HtmlHelp HH_TP_HELP_WM_HELP.
|
|
*
|
|
* The control and help ID values are identical just to make life
|
|
* simpler, but we need a table anyway.
|
|
*/
|
|
static const DWORD PopUpHelpIds[];
|
|
|
|
CString fExeFileName;
|
|
CString fExeBaseName;
|
|
};
|
|
|
|
extern MyApp gMyApp;
|
|
|
|
#endif /*APP_MYAPP_H*/
|