Josh Sled <[EMAIL PROTECTED]> writes:

>> +  GtkTreeView* treeview; /* The treeview containing the data */
>> +  GtkTreeView* ctreeview; /* The treeview containing the column types */
>> +  GtkCheckButton* sep_buttons[SEP_NUM_OF_TYPES]; /* Checkbuttons for common 
>> separators */
>> +  GtkCheckButton* custom_cbutton; /* The checkbutton for a custom separator 
>> */
>> +  GtkEntry* custom_entry; /* The entry for custom separators */
>> +  gboolean approved; /* This is FALSE until the user clicks "OK". */
>>  } GncCsvPreview;
>
> For these, for doxygen, you'll want to say /**< This is FALSE [...] */, I 
> think.

Yep, that's the doxygen format for "this comment goes to the previous
block, not the next block".

>> -static void encoding_selected(GOCharmapSel* selector, const char* enc,
>> +/* Event handler for a new encoding being selected. */
>> +static void encoding_selected(GOCharmapSel* selector, const char* encoding,
>>                                GncCsvPreview* preview)
>>  {
>> +  /* This gets called twice everytime a new encoding is selected. The
>> +   * second call actually passes the correct data; thus, we only do
>> +   * something the second time this is called. */
>>    static gboolean second_call = FALSE;
>> +  /* If this is the second time the function is called ... */
>>    if(second_call)
>
> Ick.  This stateful behavior should be avoided if at all possible.  Is there
> a way to instead be conditional on the "correctness" of the data?  Or
> eliminate the double-call?

Or put the state into the parse context and not in the function?  Yes,
"static" state is BAD.  What happens if you call the importer multiple
times?  (e.g. you're importing multiple files) The second time you run
the importer this variable will be set and you're screwed.

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [EMAIL PROTECTED]                        PGP key available
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Reply via email to