mirror of
https://github.com/fadden/ciderpress.git
synced 2024-05-29 03:41:28 +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.
58 lines
1.5 KiB
C++
58 lines
1.5 KiB
C++
/*
|
|
* CiderPress
|
|
* Copyright (C) 2007 by faddenSoft, LLC. All Rights Reserved.
|
|
* See the file LICENSE for distribution terms.
|
|
*/
|
|
/*
|
|
* File associations edit dialog.
|
|
*/
|
|
#ifndef APP_EDITASSOCDIALOG_H
|
|
#define APP_EDITASSOCDIALOG_H
|
|
#ifdef CAN_UPDATE_FILE_ASSOC
|
|
#include "resource.h"
|
|
|
|
/*
|
|
* Edit whatever associations our registry class cares about.
|
|
*/
|
|
class EditAssocDialog : public CDialog {
|
|
public:
|
|
EditAssocDialog(CWnd* pParentWnd = NULL) :
|
|
CDialog(IDD_ASSOCIATIONS, pParentWnd),
|
|
fOurAssociations(NULL)
|
|
{}
|
|
virtual ~EditAssocDialog() {
|
|
delete[] fOurAssociations;
|
|
}
|
|
|
|
// Which associations are ours. This should be left uninitialized;
|
|
// Setup() takes care of that. The caller may "steal" the array
|
|
// afterward, freeing it with delete[].
|
|
bool* fOurAssociations;
|
|
|
|
protected:
|
|
virtual BOOL OnInitDialog(void) override;
|
|
void DoDataExchange(CDataExchange* pDX) override;
|
|
|
|
afx_msg BOOL OnHelpInfo(HELPINFO* lpHelpInfo) {
|
|
return MyApp::HandleHelpInfo(lpHelpInfo);
|
|
}
|
|
afx_msg void OnHelp(void) {
|
|
MyApp::HandleHelp(this, HELP_TOPIC_EDIT_ASSOC);
|
|
}
|
|
|
|
/*
|
|
* Load the list view control.
|
|
*
|
|
* This list isn't sorted, so we don't need to stuff anything into lParam to
|
|
* keep the list and source data tied.
|
|
*
|
|
* If "loadAssoc" is true, we also populate the fOurAssocations table.
|
|
*/
|
|
void Setup(bool loadAssoc);
|
|
|
|
DECLARE_MESSAGE_MAP()
|
|
};
|
|
|
|
#endif
|
|
#endif /*APP_EDITASSOCDIALOG_H*/
|