reset Preferences CFG file

[Gale Andrews]

Even if the two apps are conjoined at the hip as it were?

No Linux distributions that I know of include the manual in the Audacity package. In fact, I don't know of any distribution that even packages the manual.

If Audacity or any other app is installed or packaged on Linux, the app ends up in root of the appropriate "bin" directory (usr/bin for system apps or usr/local/bin for installation of self-compiled apps).

I would find it reasonable if we wanted to provide an external app on Linux for the app to be a required app, not a dependent package. It would be like e.g. ffmpeg, ffplay, ffprobe and ffserver, vlc and vlc-wrapper, empathy-*, jack-* or gnome-*.


Gale

[Gale Andrews]

IF Audacity changes its name in 15 years time, and you want to argue that the author/publisher/vendor of the Nyquist Prompt should be updated, then you can argue the point in 15 years time should you wish to. I don't see much point about complaining about it now, especially as it is not certain that you would win the argument.

If what we are talking about is what would appear when the plugins are grouped by publisher, then it seems to me that if Audacity changed its name that there would be a very good case that the grouped publisher would change name too.

However it would still seem better to determine that where we display the publisher name in the Effect Menu. As Steve said, we may want to call the Publisher "built-in" or various other names could be appropriate.

Gale

[Gale Andrews]

You've convinced me that instead of messing about with audacity.cfg and/or pluginregistry.cfg we should just create resetPrefs.txt in the appropriate location. Unfortunately, I see no easy method of locating that "appropriate location"; fortunately this is a Catch-21 (not as bad as a Catch-22 <grin>). Only Audacity knows where the "appropriate location" is and, currently, it only knows this when it is running.

So, the external app does not know the folder it is located in and cannot be made to write to the folder it is in?

It would be fairly trivial to have Audacity create a new file in the same folder as audacity.cfg and pluginregistry.cfg; this would be a simple text file (or maybe XML?) with a single line containing the fully qualified path to said "appropriate location".

What happens if we have never run Audacity before and Audacity can't get as far as creating its folder for application data?

Although there is no method for an external application to "calculate" Audacity's configuration folder, the external application can make the assumption that, if both Audacity and said external application are built at the same time and from within the same source tree, the external application can have all the information that Audacity uses to create its configuration folder. This means that the external application can look in Audacity's configuration folder for the above-mentioned text file, read that single line containing the fully qualified path to Audacity's containing folder and then create the new resetPrefs.txt file.

Since we can't assume that Audacity's folder for application data exists, can this line of argument lead anywhere?


Gale

[Gale Andrews]

So where are we going with the single button in Prefs, as per Ed's patch? I've tested it on all three platforms.

Given this would probably be too much of a feature change for 2.1.0, should I just post the patch with whatever text changes I see fit in http://bugzilla.audacityteam.org/show_bug.cgi?id=363 and update http://wiki.audacityteam.org/wiki/Propo ... _cfg_Reset?

Did anyone else have comments on how the patch works/what it does?


Gale

[Edgar]

Only Audacity knows where the "appropriate location" is and, currently, it only knows this when it is running.

So, the external app does not know the folder it is located in and cannot be made to write to the folder it is in?

Not exactly, the external app knows its location and could even determine if Audacity.exe was located in that location. The only problem with this is the potential, given the vagaries of a single identical solution for all three operating systems (and their flavors), of the two applications actually not cohabitating a single folder.

It would be fairly trivial to have Audacity create a new file in the same folder as audacity.cfg and pluginregistry.cfg; this would be a simple text file (or maybe XML?) with a single line containing the fully qualified path to said "appropriate location".

What happens if we have never run Audacity before and Audacity can't get as far as creating its folder for application data?

In this situation, by definition, the problem cannot be repaired by resetting/removing Audacity's configuration file(s). It might also be a good argument that the installer should try to create "Audacity's folder for application data/install.log" or some similar file as a simple test that said location can be written to - but it only tells us for the installer's permissions, not necessarily the user's permissions.

Although there is no method for an external application to "calculate" Audacity's configuration folder, the external application can make the assumption that, if both Audacity and said external application are built at the same time and from within the same source tree, the external application can have all the information that Audacity uses to create its configuration folder. This means that the external application can look in Audacity's configuration folder for the above-mentioned text file, read that single line containing the fully qualified path to Audacity's containing folder and then create the new resetPrefs.txt file.

Since we can't assume that Audacity's folder for application data exists, can this line of argument lead anywhere?

The code would have error checking so that if the external application was unable to read the "appropriate location" because Audacity's folder for application data did not exist it would terminate without taking any action (it could pop up a dialog saying that it did not believe that Audacity had ever run before and thus could/need not reset its configuration file).

The code for the external application could be robust enough to cover both of these bases:

• 0) determine if the potential location of Audacity's folder for application data is local (/Portable/) or in the /user/ folder hierarchy
  1) check to see if Audacity has written its location in its potential folder for application data
  2) if so use that information to see if Audacity.exe actually does reside in said Audacity folder
  3) if so create the new resetPrefs.txt file in said Audacity folder and exit
  4) check to see if Audacity.exe is in the external application's containing folder
  5) if so create the new resetPrefs.txt file in said containing folder and exit
  6) if not display a folder finder dialog (wxWidgets has one) and allow the user to find the folder containing Audacity.exe
  7) check to see if Audacity.exe is in the folder found by the user
  8) if so create the new resetPrefs.txt file in said user-found folder and exit
  9) if not display a dialog which allows the user to go back to step six or to exit unsuccessfully

One reason for not using the "create resetPrefs.txt file" solution is that it is possible that Audacity.exe could theoretically exist in multiple locations. If the user's desktop shortcut did not point to Audacity in the same folder as the one in which resetPrefs.txt was created the reset would fail to happen. If the external app actually did the job of deleting the configuration file(s), it could first look for the existence of BOTH "external app's containing folder/Audacity.exe" AND "external app's containing folder/Portable/" (i.e. Audacity is configured for Portability and Audacity resides in the external app's containing folder) and then (using logic similar to the above) delete the configuration files in /Portable/ if they exist AND(/or?) those in Audacity's configuration folder.

[Gale Andrews]

Only Audacity knows where the "appropriate location" is and, currently, it only knows this when it is running.

So, the external app does not know the folder it is located in and cannot be made to write to the folder it is in?

Not exactly, the external app knows its location and could even determine if Audacity.exe was located in that location. The only problem with this is the potential, given the vagaries of a single identical solution for all three operating systems (and their flavors), of the two applications actually not cohabitating a single folder.

This solution requires us to commit to including the external reset app alongside the Audacity application (though we may not do this for Linux).

So if the two apps do not cohabit, that means the user moved one of them. Our instructions will say not to move the reset app, and the app could show an error if the Audacity executable is not in the same folder as the reset app.

We would still have to be sure this solution would work on Mac. If the app determines that Audacity.app is present in the same folder, then it has to write to the known relative path "/Audacity.app/Contents/Resources/" . Can it do that?

What happens if we have never run Audacity before and Audacity can't get as far as creating its folder for application data?

In this situation, by definition, the problem cannot be repaired by resetting/removing Audacity's configuration file(s).

I guess you're right. Perhaps a better question would be to ensure that your file containing the path to Audacity was created as soon as possible after the application data folder was created.

The code for the external application could be robust enough to cover both of these bases: determine if the potential location of Audacity's folder for application data is local (/Portable/) or in the /user/ folder hierarchy

OK, but resetPrefs txt only resets one audacity.cfg. If there is a Portable Settings folder where resetPrefs.txt exists, then the audacity.cfg in that folder is initialised. So the feature you mention does not seem to be needed unless you propose to reset audacity.cfg in the application data folder as well as the one in "Portable Settings ". See also below.

One reason for not using the "create resetPrefs.txt file" solution is that it is possible that Audacity.exe could theoretically exist in multiple locations. If the user's desktop shortcut did not point to Audacity in the same folder as the one in which resetPrefs.txt was created the reset would fail to happen.

Yes, that could happen if Audacity was obtained in a zip file rather than in an installer.

Assuming the external app is shipped in the same folder as the Audacity executable, it should be fairly intuitive that one is explicitly acting on Audacity which resides in the folder one is running the external app from. I agree a user with multiple Audacity versions could assume otherwise, so perhaps the external app could show a confirmation dialogue that said:

Reset request activated. When you next launch <path to audacity executable in the external app's folder> you will be asked to confirm that you wish to reset Audacity Preferences.

If the external app actually did the job of deleting the configuration file(s), it could first look for the existence of BOTH "external app's containing folder/Audacity.exe" AND "external app's containing folder/Portable/" (i.e. Audacity is configured for Portability and Audacity resides in the external app's containing folder) and then (using logic similar to the above) delete the configuration files in /Portable/ if they exist AND(/or?) those in Audacity's configuration folder.

Indeed, but that's only a benefit over resetPreferences.txt if we want to delete all possible audacity.cfg files (i.e. the one in the user's application data folder and however many there are in "Portable Settings" folders for various Audacity versions scattered across the computer). I'm not sure we want to do that - it's possible for example that a desirable set of settings called "audacity.cfg" could have been stored by the user in another Audacity folder. Perhaps it's better not to make assumptions?

As you said, an external app not relying on resetPreferences.txt could backup the audacity.cfg it deleted, but resetPreferences.txt could also do that if we modified the code that file triggers.


Gale

[Edgar]

So if the two apps do not cohabit, that means the user moved one of them. Our instructions will say not to move the reset app, and the app could show an error if the Audacity executable is not in the same folder as the reset app.

We would still have to be sure this solution would work on Mac. If the app determines that Audacity.app is present in the same folder, then it has to write to the known relative path "/Audacity.app/Contents/Resources/" . Can it do that?

Yes, the external application should and could show an error dialog if it could not locate some critical file.

I firmly believe that any solution should work on all three platforms - whatever that takes. As long as the "known relative path" remains known with operating system upgrades it should work just fine but, as you say, would need to be carefully tested on Mac.

As you said, an external app not relying on resetPreferences.txt could backup the audacity.cfg it deleted, but resetPreferences.txt could also do that if we modified the code that file triggers.

Backing up and restoring Audacity's configuration file adds an extra layer of user support but adds a lot of complication - a lot more code, a lot more potential for filesystem errors, a lot more GUI and user preferences - probably impossible to sell. As Steve points out in another thread - KISS is our watchword if we want to sell this to Team Audacity.

[Gale Andrews]

Leland has not found a way yet to make your Windows external reset app into a Mac app.

My external reset app should not be too difficult to compile on Mac and Linux. Can you compile any of the wxWidgets sample applications? I started with the controls sample. Start with Windows:
1) make a copy of that folder (%WXWIN%samplescontrols) within its parent folder (%WXWIN%samples)*
2) rename it "resetAudacity" or anything obvious and different from the name of the folder in which my current code resides
3) copy reset.cpp & reset.h from the folder in which my current code resides into this new "resetAudacity" folder
4) within "resetAudacity" delete both controls.cpp & controls.h (or rename them: "old controls.cpp" etc.)
5) within "resetAudacity" rename my files: reset.cpp becomes controls.cpp & reset.h becomes controls.h*
6) open folder "resetAudacity" up and start the included MS VS solution
7) compile and test this application which will be called controls.exe

On Mac & Linux follow the above instructions 1-5 then:
6) open a terminal and CD to this new "resetAudacity" folder
7) use "make" as you normally would (my understanding is that at the terminal prompt you just type:

Code: Select all

make

and press <ENTER> and everything should just proceed automatically from there resulting in a new application which will be called controls.exe.


*This just keeps the compiler and makefile happy about the location of wxWidgets include files and libraries.

Hi Ed,

I won't bother on Windows as I could compile it there anyway.

On Mac I did what you said, except there is no controls.h, and I had to either change the include in the renamed controls.cpp to "controls.h", or keep the original name of reset.h.

Both methods produce the below.


Gale

Code: Select all

Mac-mini:resetAudacity gale$ make
/Users/gale/Downloads/wxMac-2.8.12/bk-deps g++ -c -o controls_controls.o -D__WXMAC__     -I. -DWXUSINGDLL -I./../../samples -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -I/Users/gale/Downloads/wxMac-2.8.12/lib/wx/include/mac-ansi-release-2.8 -I../../include -fpascal-strings -I../../src/mac/carbon/morefilex -I/Developer/Headers/FlatCarbon -DWX_PRECOMP -Wall -Wundef -Wno-ctor-dtor-privacy -O2 -fno-strict-aliasing -fno-common ./controls.cpp
./controls.cpp:25:25: warning: extra tokens at end of #include directive [-Wextra-tokens]
#include <wx/fileconf.h>F
                        ^
                        //
./controls.cpp:36:10: error: expected "FILENAME" or <FILENAME>
#include “reset.h”
         ^
./controls.cpp:38:19: error: use of undeclared identifier 'MyFrame'; did you mean 'wxFrame'?
BEGIN_EVENT_TABLE(MyFrame, wxFrame)
                  ^~~~~~~
                  wxFrame
../../include/wx/event.h:2721:24: note: expanded from macro 'BEGIN_EVENT_TABLE'
    const wxEventTable theClass::sm_eventTable = 
                       ^
../../include/wx/mac/carbon/menu.h:15:19: note: 'wxFrame' declared here
class WXDLLEXPORT wxFrame;
                  ^
./controls.cpp:38:19: error: use of undeclared identifier 'MyFrame'; did you mean 'wxFrame'?
BEGIN_EVENT_TABLE(MyFrame, wxFrame)
                  ^~~~~~~
                  wxFrame
../../include/wx/event.h:2722:39: note: expanded from macro 'BEGIN_EVENT_TABLE'
        { &baseClass::sm_eventTable, &theClass::sm_eventTableEntries[0] }; 
                                      ^
../../include/wx/mac/carbon/menu.h:15:19: note: 'wxFrame' declared here
class WXDLLEXPORT wxFrame;
                  ^
./controls.cpp:38:19: error: use of undeclared identifier 'MyFrame'; did you mean 'wxFrame'?
BEGIN_EVENT_TABLE(MyFrame, wxFrame)
                  ^~~~~~~
                  wxFrame
../../include/wx/event.h:2723:25: note: expanded from macro 'BEGIN_EVENT_TABLE'
    const wxEventTable *theClass::GetEventTable() const 
                        ^
../../include/wx/mac/carbon/menu.h:15:19: note: 'wxFrame' declared here
class WXDLLEXPORT wxFrame;
                  ^
./controls.cpp:38:19: error: use of undeclared identifier 'MyFrame'; did you mean 'wxFrame'?
BEGIN_EVENT_TABLE(MyFrame, wxFrame)
                  ^~~~~~~
                  wxFrame
../../include/wx/event.h:2724:19: note: expanded from macro 'BEGIN_EVENT_TABLE'
        { return &theClass::sm_eventTable; } 
                  ^
../../include/wx/mac/carbon/menu.h:15:19: note: 'wxFrame' declared here
class WXDLLEXPORT wxFrame;
                  ^
./controls.cpp:38:19: error: use of undeclared identifier 'MyFrame'; did you mean 'wxFrame'?
BEGIN_EVENT_TABLE(MyFrame, wxFrame)
                  ^~~~~~~
                  wxFrame
../../include/wx/event.h:2725:22: note: expanded from macro 'BEGIN_EVENT_TABLE'
    wxEventHashTable theClass::sm_eventHashTable(theClass::sm_eventTable); 
                     ^
../../include/wx/mac/carbon/menu.h:15:19: note: 'wxFrame' declared here
class WXDLLEXPORT wxFrame;
                  ^
./controls.cpp:38:19: error: use of undeclared identifier 'MyFrame'; did you mean 'wxFrame'?
BEGIN_EVENT_TABLE(MyFrame, wxFrame)
                  ^~~~~~~
                  wxFrame
../../include/wx/event.h:2725:50: note: expanded from macro 'BEGIN_EVENT_TABLE'
    wxEventHashTable theClass::sm_eventHashTable(theClass::sm_eventTable); 
                                                 ^
../../include/wx/mac/carbon/menu.h:15:19: note: 'wxFrame' declared here
class WXDLLEXPORT wxFrame;
                  ^
./controls.cpp:38:19: error: use of undeclared identifier 'MyFrame'; did you mean 'wxFrame'?
BEGIN_EVENT_TABLE(MyFrame, wxFrame)
                  ^~~~~~~
                  wxFrame
../../include/wx/event.h:2726:23: note: expanded from macro 'BEGIN_EVENT_TABLE'
    wxEventHashTable &theClass::GetEventHashTable() const 
                      ^
../../include/wx/mac/carbon/menu.h:15:19: note: 'wxFrame' declared here
class WXDLLEXPORT wxFrame;
                  ^
./controls.cpp:38:19: error: use of undeclared identifier 'MyFrame'; did you mean 'wxFrame'?
BEGIN_EVENT_TABLE(MyFrame, wxFrame)
                  ^~~~~~~
                  wxFrame
../../include/wx/event.h:2727:18: note: expanded from macro 'BEGIN_EVENT_TABLE'
        { return theClass::sm_eventHashTable; } 
                 ^
../../include/wx/mac/carbon/menu.h:15:19: note: 'wxFrame' declared here
class WXDLLEXPORT wxFrame;
                  ^
./controls.cpp:38:19: error: use of undeclared identifier 'MyFrame'; did you mean 'wxFrame'?
BEGIN_EVENT_TABLE(MyFrame, wxFrame)
                  ^~~~~~~
                  wxFrame
../../include/wx/event.h:2728:29: note: expanded from macro 'BEGIN_EVENT_TABLE'
    const wxEventTableEntry theClass::sm_eventTableEntries[] = { 
                            ^
../../include/wx/mac/carbon/menu.h:15:19: note: 'wxFrame' declared here
class WXDLLEXPORT wxFrame;
                  ^
./controls.cpp:39:15: error: use of undeclared identifier 'ID_GLOBALRESETALL'
   EVT_BUTTON(ID_GLOBALRESETALL, MyFrame::OnResetAll)
              ^
../../include/wx/event.h:3031:82: note: expanded from macro 'EVT_BUTTON'
#  define EVT_BUTTON(winid, func) wx__DECLARE_EVT1(wxEVT_COMMAND_BUTTON_CLICKED, winid, wxCommandEventHandler(func))
                                                                                 ^
../../include/wx/event.h:2851:27: note: expanded from macro 'wx__DECLARE_EVT1'
    wx__DECLARE_EVT2(evt, id, wxID_ANY, fn)
                          ^
../../include/wx/event.h:2849:36: note: expanded from macro 'wx__DECLARE_EVT2'
    DECLARE_EVENT_TABLE_ENTRY(evt, id1, id2, fn, NULL),
                                   ^
../../include/wx/event.h:96:29: note: expanded from macro 'DECLARE_EVENT_TABLE_ENTRY'
    wxEventTableEntry(type, winid, idLast, fn, obj)
                            ^
./controls.cpp:40:15: error: use of undeclared identifier 'ID_GLOBALRESETBASE'
   EVT_BUTTON(ID_GLOBALRESETBASE, MyFrame::OnResetBase)
              ^
../../include/wx/event.h:3031:82: note: expanded from macro 'EVT_BUTTON'
#  define EVT_BUTTON(winid, func) wx__DECLARE_EVT1(wxEVT_COMMAND_BUTTON_CLICKED, winid, wxCommandEventHandler(func))
                                                                                 ^
../../include/wx/event.h:2851:27: note: expanded from macro 'wx__DECLARE_EVT1'
    wx__DECLARE_EVT2(evt, id, wxID_ANY, fn)
                          ^
../../include/wx/event.h:2849:36: note: expanded from macro 'wx__DECLARE_EVT2'
    DECLARE_EVENT_TABLE_ENTRY(evt, id1, id2, fn, NULL),
                                   ^
../../include/wx/event.h:96:29: note: expanded from macro 'DECLARE_EVENT_TABLE_ENTRY'
    wxEventTableEntry(type, winid, idLast, fn, obj)
                            ^
./controls.cpp:41:15: error: use of undeclared identifier 'ID_GLOBALRESETPLUGIN'
   EVT_BUTTON(ID_GLOBALRESETPLUGIN, MyFrame::OnResetPlugin)
              ^
../../include/wx/event.h:3031:82: note: expanded from macro 'EVT_BUTTON'
#  define EVT_BUTTON(winid, func) wx__DECLARE_EVT1(wxEVT_COMMAND_BUTTON_CLICKED, winid, wxCommandEventHandler(func))
                                                                                 ^
../../include/wx/event.h:2851:27: note: expanded from macro 'wx__DECLARE_EVT1'
    wx__DECLARE_EVT2(evt, id, wxID_ANY, fn)
                          ^
../../include/wx/event.h:2849:36: note: expanded from macro 'wx__DECLARE_EVT2'
    DECLARE_EVENT_TABLE_ENTRY(evt, id1, id2, fn, NULL),
                                   ^
../../include/wx/event.h:96:29: note: expanded from macro 'DECLARE_EVENT_TABLE_ENTRY'
    wxEventTableEntry(type, winid, idLast, fn, obj)
                            ^
./controls.cpp:42:24: error: use of undeclared identifier 'MyFrame'; did you mean 'wxFrame'?
   EVT_MENU(wxID_EXIT, MyFrame::OnQuit)
                       ^~~~~~~
                       wxFrame
../../include/wx/event.h:3026:106: note: expanded from macro 'EVT_MENU'
#define EVT_MENU(winid, func) wx__DECLARE_EVT1(wxEVT_COMMAND_MENU_SELECTED, winid, wxCommandEventHandler(func))
                                                                                                         ^
../../include/wx/event.h:2627:88: note: expanded from macro 'wxCommandEventHandler'
    (wxObjectEventFunction)(wxEventFunction)wxStaticCastEvent(wxCommandEventFunction, &func)
                                                                                       ^
../../include/wx/event.h:52:59: note: expanded from macro 'wxStaticCastEvent'
#define wxStaticCastEvent(type, val) wx_static_cast(type, val)
                                                          ^
note: (skipping 1 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
../../include/wx/event.h:2851:41: note: expanded from macro 'wx__DECLARE_EVT1'
    wx__DECLARE_EVT2(evt, id, wxID_ANY, fn)
                                        ^
../../include/wx/event.h:2849:46: note: expanded from macro 'wx__DECLARE_EVT2'
    DECLARE_EVENT_TABLE_ENTRY(evt, id1, id2, fn, NULL),
                                             ^
../../include/wx/event.h:96:44: note: expanded from macro 'DECLARE_EVENT_TABLE_ENTRY'
    wxEventTableEntry(type, winid, idLast, fn, obj)
                                           ^
../../include/wx/mac/carbon/menu.h:15:19: note: 'wxFrame' declared here
class WXDLLEXPORT wxFrame;
                  ^
./controls.cpp:42:33: error: no member named 'OnQuit' in 'wxFrame'
   EVT_MENU(wxID_EXIT, MyFrame::OnQuit)
                       ~~~~~~~~~^
../../include/wx/event.h:3026:106: note: expanded from macro 'EVT_MENU'
#define EVT_MENU(winid, func) wx__DECLARE_EVT1(wxEVT_COMMAND_MENU_SELECTED, winid, wxCommandEventHandler(func))
                                                                                                         ^
../../include/wx/event.h:2627:88: note: expanded from macro 'wxCommandEventHandler'
    (wxObjectEventFunction)(wxEventFunction)wxStaticCastEvent(wxCommandEventFunction, &func)
                                                                                       ^
../../include/wx/event.h:52:59: note: expanded from macro 'wxStaticCastEvent'
#define wxStaticCastEvent(type, val) wx_static_cast(type, val)
                                                          ^
note: (skipping 1 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
../../include/wx/event.h:2851:41: note: expanded from macro 'wx__DECLARE_EVT1'
    wx__DECLARE_EVT2(evt, id, wxID_ANY, fn)
                                        ^
../../include/wx/event.h:2849:46: note: expanded from macro 'wx__DECLARE_EVT2'
    DECLARE_EVENT_TABLE_ENTRY(evt, id1, id2, fn, NULL),
                                             ^
../../include/wx/event.h:96:44: note: expanded from macro 'DECLARE_EVENT_TABLE_ENTRY'
    wxEventTableEntry(type, winid, idLast, fn, obj)
                                           ^
./controls.cpp:43:25: error: use of undeclared identifier 'MyFrame'; did you mean 'wxFrame'?
   EVT_MENU(wxID_ABOUT, MyFrame::OnAbout)
                        ^~~~~~~
                        wxFrame
../../include/wx/event.h:3026:106: note: expanded from macro 'EVT_MENU'
#define EVT_MENU(winid, func) wx__DECLARE_EVT1(wxEVT_COMMAND_MENU_SELECTED, winid, wxCommandEventHandler(func))
                                                                                                         ^
../../include/wx/event.h:2627:88: note: expanded from macro 'wxCommandEventHandler'
    (wxObjectEventFunction)(wxEventFunction)wxStaticCastEvent(wxCommandEventFunction, &func)
                                                                                       ^
../../include/wx/event.h:52:59: note: expanded from macro 'wxStaticCastEvent'
#define wxStaticCastEvent(type, val) wx_static_cast(type, val)
                                                          ^
note: (skipping 1 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
../../include/wx/event.h:2851:41: note: expanded from macro 'wx__DECLARE_EVT1'
    wx__DECLARE_EVT2(evt, id, wxID_ANY, fn)
                                        ^
../../include/wx/event.h:2849:46: note: expanded from macro 'wx__DECLARE_EVT2'
    DECLARE_EVENT_TABLE_ENTRY(evt, id1, id2, fn, NULL),
                                             ^
../../include/wx/event.h:96:44: note: expanded from macro 'DECLARE_EVENT_TABLE_ENTRY'
    wxEventTableEntry(type, winid, idLast, fn, obj)
                                           ^
../../include/wx/mac/carbon/menu.h:15:19: note: 'wxFrame' declared here
class WXDLLEXPORT wxFrame;
                  ^
./controls.cpp:43:34: error: no member named 'OnAbout' in 'wxFrame'
   EVT_MENU(wxID_ABOUT, MyFrame::OnAbout)
                        ~~~~~~~~~^
../../include/wx/event.h:3026:106: note: expanded from macro 'EVT_MENU'
#define EVT_MENU(winid, func) wx__DECLARE_EVT1(wxEVT_COMMAND_MENU_SELECTED, winid, wxCommandEventHandler(func))
                                                                                                         ^
../../include/wx/event.h:2627:88: note: expanded from macro 'wxCommandEventHandler'
    (wxObjectEventFunction)(wxEventFunction)wxStaticCastEvent(wxCommandEventFunction, &func)
                                                                                       ^
../../include/wx/event.h:52:59: note: expanded from macro 'wxStaticCastEvent'
#define wxStaticCastEvent(type, val) wx_static_cast(type, val)
                                                          ^
note: (skipping 1 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
../../include/wx/event.h:2851:41: note: expanded from macro 'wx__DECLARE_EVT1'
    wx__DECLARE_EVT2(evt, id, wxID_ANY, fn)
                                        ^
../../include/wx/event.h:2849:46: note: expanded from macro 'wx__DECLARE_EVT2'
    DECLARE_EVENT_TABLE_ENTRY(evt, id1, id2, fn, NULL),
                                             ^
../../include/wx/event.h:96:44: note: expanded from macro 'DECLARE_EVENT_TABLE_ENTRY'
    wxEventTableEntry(type, winid, idLast, fn, obj)
                                           ^
./controls.cpp:46:15: error: unknown type name 'MyApp'
IMPLEMENT_APP(MyApp)
              ^
../../include/wx/app.h:688:29: note: expanded from macro 'IMPLEMENT_APP'
    IMPLEMENT_APP_NO_THEMES(appname)        
                            ^
../../include/wx/app.h:682:27: note: expanded from macro 'IMPLEMENT_APP_NO_THEMES'
    IMPLEMENT_APP_NO_MAIN(appname)          
                          ^
../../include/wx/app.h:672:20: note: expanded from macro 'IMPLEMENT_APP_NO_MAIN'
        return new appname;                                                 
                   ^
./controls.cpp:46:15: error: unknown type name 'MyApp'
../../include/wx/app.h:688:29: note: expanded from macro 'IMPLEMENT_APP'
    IMPLEMENT_APP_NO_THEMES(appname)        
                            ^
../../include/wx/app.h:682:27: note: expanded from macro 'IMPLEMENT_APP_NO_THEMES'
    IMPLEMENT_APP_NO_MAIN(appname)          
                          ^
../../include/wx/app.h:676:17: note: expanded from macro 'IMPLEMENT_APP_NO_MAIN'
    DECLARE_APP(appname)                                                    
                ^
../../include/wx/app.h:698:37: note: expanded from macro 'DECLARE_APP'
#define DECLARE_APP(appname) extern appname& wxGetApp();
                                    ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
1 warning and 20 errors generated.
make: *** [controls_controls.o] Error 1

[Edgar]

Both methods produce the below.

Code: Select all

./controls.cpp:25:25: warning: extra tokens at end of #include directive [-Wextra-tokens]
#include <wx/fileconf.h>F
                        ^
                        //
./controls.cpp:36:10: error: expected "FILENAME" or <FILENAME>
#include “reset.h”

Sorry…

Code: Select all

#include “reset.h”

must be changed to:

Code: Select all

#include “controls.h”

and it looks like:

Code: Select all

#include <wx/fileconf.h>F

is telling us that the file endings must be converted for both these files (.cpp &.h) or somehow that capital f (<F>) at the end of that line managed to sneak in (download error?). That is the reason why you should start with building/testing the Windows solution - just as a sanity check.

[Gale Andrews]

That is the reason why you should start with building/testing the Windows solution - just as a sanity check.

Well, you can do that, Ed, if you haven't already

I doubt there is an error in my build of wxMac as I build Audacity regularly on Mac.

I can't find anything useful by Googling, but might this be a missing include? Try asking Leland if you're not sure where to go from here.


Gale