From: Francesco M. <f18...@ya...> - 2005-09-04 16:20:44
|
Hi, >>However we should consider that >>1) this will make more difficult for wxCode administrators to edit >>component categories when using the phpMyAdmin interface for editing, >>for example, unmaintained components. > > > Why? In my view it is not more complicate to check one or more category > check boxes than selecting two categories from list boxes. And if you > do it directly on the database you write two inserts instead of one, > and one of them is very simple having only the component name and the > category name as values. well, 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... >>2) this would make the website even more complex and more than 2 >>categories are not required I think. > > > I don't think so. The size of the list of categories is not influenced > by associating more than one or two categories to a component. I meant that the PHP code would have been more complex :-) As you said, the size of the category links in the complist is not a problem. > And > 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. >>another solution instead of using a different table for "categories" >>would be to use for the "category" field the SET type. this is what >>I'm doing currently for the wx ports, versions, and build system >>fields (which are rendered using listboxes but they could be rendered >>also with checkboxes). > > That's clearly an option, although it makes the application dependent > on the MySQL database since the 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. 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. >>why don't use a category like 'print/export' ? > > Excellent. To make it still a bit less specific we could call 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 only issue: if you use MSVC6 to run the sample, then it will run >>with working directory the "build" folder. Unfortunately this cannot >>be set in the DSP / DSW files by bakefile since this setting is stored >>in the OPT file. This results in a crash of tutorial samples > 3 to >>open the 20k_c1.txt, etc files... > > > To be frank, it's not the only issue with MSVC6. > > As you mentioned it would be necessary to set the working directory > when running the application from within MSVC (if you start it from the > command prompt in the samples directory it works without problems. But > there seems to be no way to do that using bakefiles. Here is a small fix adapted from my components to the tutorial3 of your comp: void tutorial3() { wxString path = wxGetCwd(); // in case this program is running from the BUILD folder... if (path.Right(5) == wxT("build")) path = path.Left(path.Len() - 6) + wxFileName::GetPathSeparator() + wxT("samples"); if (path.Last() != wxFileName::GetPathSeparator()) path += wxFileName::GetPathSeparator(); PdfTuto3 pdf; pdf.SetMyTitle(_T("20000 Leagues Under the Seas")); pdf.SetAuthor(_T("Jules Verne")); pdf.PrintChapter(1,_T("A RUNAWAY REEF"), path + _T("20k_c1.txt")); pdf.PrintChapter(2,_T("THE PROS AND CONS"),path + _T("20k_c2.txt")); pdf.SaveAsFile(_T("tutorial3.pdf")); } > Another problem arises when you build shared libraries (DLLs). 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. Maybe I should set wxCode bakefiles so that the DLL goes in the "samples" folder... 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... > 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 ? It was not a build problems: I get no warnings/errors when building. It was an unsafe use of wxFileInputStream in the samples which lead to an ASSERT in wx internal code. Obviously it disappear if I run the sample from console. > 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 :-) Francesco |