I like this GUI.... I would add a "comment" or "note" column (also to the project file)
Should be possible with a thing like this in compileoptionsbase.h:
typedef struct
{
wxString a_value;
wxString a_comment;
} wxString2;
WX_DECLARE_STRING_HASH_MAP(wxString2, String2Hash);
And with a slight modification of all code parts that uses CompileOptionsBase::m_Vars. There are not too many apparently.
I am not quite sure what obfuscated thinks about the wxDataViewListCtrl, because in the past it was quite buggy on different platforms...
U right, that is the real problem
I also do not know if we want to add this before the next release, but in general i really like this! Can you create a patch?
Patches for each file are in the "pub" branch. There is a script for linux that apply the patches automatically.
Should I rather create a patch for the whole trunk ?
Hello C::B devs. It is my intention to replace the old code for looping among CompileOptionsBase vars :
const CustomVarHash& v = object->GetAllVars();
for (CustomVarHash::const_iterator it = v.begin(); it != v.end(); ++it)
with a loop like this :
for ( CustomVarHash::const_iterator * it = object->VarEnumGetFirst(properties_flags) ; it != nullptr ; it = object->VarEnumGetNext() )
Motivation : adding active / inactive ( or any other ) property to vars leads to select the vars you want to enumerate by their properties. I want to keep this selection in CompileOptionsBase.
Would the following piece of code be accepted in C::B, because it has static vars in cpp module and it is not STL container enum. Thanx.
N.B. I am aware that m_Vars and m_ActiveVars can be merged.
~ in compileoptionsbase.cpp ~
// these variables because in CB code, GetAllVars() is assumed const. So we cant define these vars as class members, since we modify them during the enumeration
static int m_VarEnumFlags;
static CustomVarHash const * m_VarEnumHash;
static CustomVarHash::const_iterator m_VarEnumIterator;
~ Little helper ~
void CompileOptionsBase::VarEnumInit(CustomVarHash const * _i_hash) const
{
m_VarEnumHash = _i_hash;
m_VarEnumIterator = m_VarEnumHash->begin();
}
~ main search ~
CustomVarHash::const_iterator* CompileOptionsBase::VarEnumFind() const
{
while ( m_VarEnumIterator != m_VarEnumHash->end() )
{
if ( m_VarEnumIterator->second.flags & m_VarEnumFlags ) ~ this is the test I want to keep in CompileOptionsBase ~
return &m_VarEnumIterator;
m_VarEnumIterator++;
}
if ( m_VarEnumHash == &m_InactiveVars )
return nullptr;
VarEnumInit(&m_InactiveVars);
return VarEnumFind();
}
~ for(...) impl ~
CustomVarHash::const_iterator* CompileOptionsBase::VarEnumGetFirst(int _i_flags) const
{
m_VarEnumFlags = _i_flags;
VarEnumInit(&m_ActiveVars);
return VarEnumFind();
}
CustomVarHash::const_iterator* CompileOptionsBase::VarEnumGetNext() const
{
m_VarEnumIterator++;
return VarEnumFind();
}
CompileOptionsBase vars are now like this :
typedef struct
{
wxString value;
wxString comment;
int flags; ~ active / inactive vars are just 2 bits in this field ~
} CustomVar;
Since the vars can be now of several categories ( with the flags ), whose active and inactive are just two possibilities, you may want to enumerate them following these categories : typically the original C::B code targets only active vars while the CompileOptionsDialog deals with other vars categories.
The difficulty is then to enumerate a subset of a STL container, by filtering properties of the objects it contains. And with a minimal API call code. It is perfectly possible that I am not enough skilled for doing this properly. Suggestions are welcome. ( I found only std::map<Key,T,Compare,Allocator>::equal_range and std::list<T,Allocator>::remove, remove_if, which dont fit )
The simpler implementation of active and inactive vars :
- without the flags extension
- with two wxHashMaps, one for active vars, one for inactive vars
that does not lead to filtering a STL container ( coz there are 2 wxHashMaps ) may be preferable ?
> What is the goal ?
With the flags, you can extend vars properties in the future
> Performance ?
You have a supplementary filtering code, so evidently less preformance
> Ease of use ?
Yes, one line code, and CompileOptionsBase do the filtering, not the caller :
for ( CustomVarHash::const_iterator * it = object->VarEnumGetFirst(properties_flags) ; it != nullptr ; it = object->VarEnumGetNext() )
> Why don't you return a vector/array with the CustomVar struct ?
That is interesting ; I made that because I could not return the wxHashMap directly ; And I didnt want to build a filtered wxHashMap and return it ( heavy object, and the existing C::B code that calls GetAllVars() enumerates the keys, but dont uses the mapping feature). But a vector, why not ? Something like this :
virtual vector< CustomVar const & > VarGetAll(int _i_flags = eVarActive) const;
I just didnt think at it >:(. I do this and I post on github so the code can be reviewed.
By the way the name "CustomVar" in the global namespace is not satisfying to me. CompileOptionsBase::Var would be logically OK but it is heavy ? Does someone have a replacement / suggestion to make.
> I doubt someone would make 100 or 1000 variables
I know that's why I did add the flags and the filtering.
> This API is really bad for performance...
Yes ; rather like this :
~ CompileOptionsBase.h ~
std::vector< CustomVar const & > & CompileOptionsBase::VarGetAll(int _i_flags = eVarActive) const;
~ CompileOptionsBase.cpp ~
static std::vector< CustomVar const & > m_VarGetAllResult;
...
std::vector< CustomVar const & > & CompileOptionsBase::VarGetAll() const
{
~ filter the vars, fill m_VarGetAllResult, and return reference to it ~
}
The returned vector does not need to be const.
EDIT
This is wrong :
static std::vector< CustomVar const & > m_VarGetAllResult;
wont compile :
error: ‘struct std::_Vector_base<const CustomVar&, std::allocator<const CustomVar&> >::_Vector_impl’ has no member named ‘_M_finish’
std::_Destroy(this->_M_impl._M_start, this->_M_impl._M_finish,
"forming pointer to reference type"