On Sun, 1 Sep 2002 20:12:44 -0700 (Pacific Daylight Time) Michael A Chase <[EMAIL PROTECTED]> wrote:
MAC> I am working on a patch that should close this bug. Wow, great! MAC> 1. I think I need to add new ORC_T_* and OAC_T_* values to the end of MAC> their lists since it looks like the encoded "Settings" string for each MAC> filter rule uses the enum values, but I want to be sure. I think you only need 2 new OAC_T_* values, e.g. OAC_T_SetFlag and OAC_T_ClearFlag -- or maybe just one if you can combine both actions somehow. You're right that the encoded Settings string uses these values (which is why you shouldn't change their numeric values!) but ORC_T_ is for the new tests, so why do you need it? MAC> 2. What names should I use for flags? I am leaning toward the MAC> one-character names given in M/doc/HtmlHlp/Manual.html (* = MAC> Flagged/Important, A = Answered, D = Deleted, U = Unread, R = Recent). Looks ok for me. MAC> I could treat 'N' (New) as both 'U' and 'R'. It's not clear what clearing 'N' flag would do and also note that you cannot change 'R' flag at all. So "N" is really just the same as "U". MAC> 3. I'd like to provide a selection list similar to ORC_W_* for flag names, MAC> but substituting it for the Where list in the filters dialog box and in the MAC> settings reading and writing is probably beyond my skill. It's not very difficult now that I made it possible to customize the GUI controls used for the filter editing (I needed to do it when working on the isSPAM filter). Basicly you need to modify OneCritControl (in src/gui/wxFilterDialogs.cpp) to do something special for OAC_T_Set/ClearFlag in its OneCritControl::UpdateUI() -- just as it currently does for OAC_T_IsSpam. MAC> 4. Since support scoring is not currently available, should the scoring MAC> values and actions in MFilter.h, MFilter.cpp, wxFiltersDialog.cpp be hidden MAC> by USE_HEADER_SCORE? To avoid invalidating old filters, I could leave them MAC> defined in Filters.cpp, but an error might be better since they don't do MAC> anything at this time. It would indeed be nice to use USE_HEADER_SCORE everywhere. The only subtlety is that the values of the enum elements should not be changed (see above) somehow. The easiest way to do it would probably be to keep them in the enum but put some special marker (e.g. empty string) in the corresponding arrays #ifndef USE_HEADER_SCORE and recognize this marker in the GUI code by simply skipping the corresponding fields. Please let me know if you have any other questions! VZ ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Mahogany-Developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-developers
