Re: [wxCode-users] wxCode categories (please ALL read)

[Ulrich T. <Ulr...@gm...>]

Hi,

> I meant to say that from phpMyAdmin before updating the values in the
> "category" field, you need to go in the "categories" table and look
> the ID of the category name you want to set; not a major issue
> obviously... 

Obviously not, since you have to know the IDs of the categories 
regardless of where you enter them, into the component table or in any 
other table.

> I meant that the PHP code would have been more complex :-)

So what? These extra lines of code are written only once.

> > probably very few components will have more than one or two assicated 
> > categories, but in case a component fits in more categories the 
> > maintainer would be free to do so.
> this is why I'm reluctant to add this... few components would need it.

I knew this argument would come. :-)

Nevertheless I think it's a good idea to be prepared for components 
which fit in more than one category. There already are such components 
in wxCode.

> > SET type is not SQL standard.
> ops; I'm not so expert in databases: I did not know when I created the
> components table that SET is MySQL-specific. 

It is, but most probably MySQL will be around long enough so we don't 
need to worry about that.

> Still, since I know how to handle SETs reliably in PHP and I have
> already some utility functions in the website for them, I would prefer
> this way rather than a new table, if we are going to add the
> multiple-categories feature. 

In my opinion the multiple-catgories feature should be added. It's ok 
to use the MySQL SET type to implement it.

> > 'print/import/export'
> that could be another good name but breaks the logical "link" between
> the PRINT concept and the EXPORT concept which have much in common.
> maybe it's best to add 
>     'import' and 'print/export'
> or
>     'import/export' and 'print'

The latter seems to be more appropriate.

> Here is a small fix adapted from my components to the tutorial3 of your comp:

Thanks. Maybe a better approach would be to change the working 
directory in minimal.cpp, otherwise I would have to change each example 
program which needs to access files. Unfortunately there is no 
wxSetCwd.

> > The DLL is placed into the folder 'lib', but if you execute the application, 
> > the DLL is not found if it is not located in the samples folder or the 
> > lib folder is not contained in the PATH environment variable.
> yes, I know; I have the same problem with my comopnents.
> And I don't know if there is some good system to avoid this.

I've no idea either. :-(

> Maybe I should set wxCode bakefiles so that the DLL goes in the
> "samples" folder...

No, please don't do that. The lib folder is the right place for LIB and 
DLL files. 

> but then it would be not very intuitive for the user: he should copy
> the .lib from the LIB folder and the .dll from the SAMPLES folder... 

This should be avoided.

Unfortunately I don't know whether it is possible in MSVC6 to specify 
where DLLs should be searched, when excuting/debugging an application 
from within MSVC.

> > The third problem is not really a big problem, but a bit inconvenient: 
> > the warning level is set to 4 in the dsp files by bakefile. This leads 
> > to dozens of warnings which can savely be ignored, but it makes 
> > locating error messages more diffcult.
> do you mean the crash I told you in the last mail ?

No. If you set the warning level to 4 before compiling minimal.cpp 
you'll see what I mean. At least in the Unicode DLL Debug build I get 
30 warnings, almost all in MSVC standard include files.

> > Maybe I should write a small readme file mentioning these issues.
> I strongly suggest you to do so: otherwise you'll get tons of mails of
> user asking help all on this same matter :-) 

Yeah, I guess you're absolutely right.

Ulrich
-- 
E-Mail privat:  Ulr...@gm...
E-Mail Studium: Ulr...@Fe...
World Wide Web: http://www.stud.fernuni-hagen.de/q1471341