From: Vidar H. <has...@bt...> - 2007-09-15 16:20:02
|
Hi Mark, > Maybe someone who is more of an OCF expert may be able to help me with this one? This may have something to do with the lack of replies. :-) I'm no expert on OCF; in fact I've never used it, so I'm sure you are = far more of an expert than I am. But here are some comments anyway. > There is a problem with TRegTemplateList (which is used by OCF) with = the Unicode build. Basically, it has an "EnabledFlags" member which is a = TCHAR. [...] However, I'm not sure it is the best way to solve it. I think that = we could just change EnabledFlags to always be a char. Your fix is probably sufficient. It may even be the best and most = compatible solution if code already depends on EnabledFlags using TCHAR. But = ideally EnabledFlags shouldn't use TCHAR. It is not an array of characters. It should be changed to an int (an int8 if space is an issue). Then again, as far as I can understand the code, the whole = implementation has problems. 128 activations causes an entry in the list to be disabled = due to overflow. Since there's no Deactivate, i.e. no decrement, I see no = point in using an incrementing flag. Why not: enum Status {Disabled, Enabled, Activated}; std::vector <Status> StatusList; // replaces EnabledList > [OCF Server crash] I have tracked it down to the "Creator" member of TAppDescriptor. [...] This causes the crash. I'm not sure what the best = plan is to solve this as there seems no easy place to set Creator to NULL due = to the way it is deleted through delegation. The obvious problem is that Creator is deleted despite having a = reference to it (in TAppDescriptor). This is the kind of problem that = reference-counted pointers (smart pointers) solve. But I don't have the OCF source = installed so I'm probably of little help here.=20 Regards, Vidar Hasfjord |