wxcode-users — Submission, Questions, Information

[wxCode-users] Cron job: wxHyperLink is pending approval

[Francesco <fr...@us...>]

name: wxHyperLink
wxversion: 
category: gui
language: cpp
description: wxHyperLink contains a static text element which links to an URL. Clicking on
the URL activates the standard browser (via mimetype) and opens the URL. No 
checks on the URL is done.
location: hyperlink
cdate: 2004-12-23
id: 64
status: stable
docs: notavailable
buildsys: 
extdep: 
wiki: disabled
wxport: 
samples: 0
approved: 0
author: Otto Wyss
version: 2004-12-23
mantainerid: 8

[wxCode-users] Cron job: wxCrashPrint is pending approval

[Francesco <fr...@us...>]

name: wxCrashPrint
wxversion: 
category: gui
language: cpp
description: This class formats and prints a report in case the application crashes on
Linux. Also included is the implementation of the BlackBox.dll which does 
the same on Windows.
location: crashprint
cdate: 2004-12-23
id: 63
status: stable
docs: hand
buildsys: 
extdep: 
wiki: disabled
wxport: wxx11
samples: 1
approved: 0
author: Otto Wyss
version: 2004-12-23
mantainerid: 8

[wxCode-users] Cron job: shortcutpanel is pending approval

[Francesco <fr...@us...>]

name: shortcutpanel
wxversion: 2.4,2.5,2.6,cvs
category: gui
language: cpp
description: Originally written by Jonatan Magnusson of Phoenix Data, this component provides an
old-style "Outlook-like" shortcut bar within a wxPanel derived class.
location: shortcutpanel
cdate: 0000-00-00
id: 68
status: stable
docs: hand
buildsys: makefiles,projectfiles
extdep: 
wiki: disabled
wxport: wxmsw,wxgtk
samples: 1
approved: 0
author: Joe Blough
version: 1.0
mantainerid: 9

[wxCode-users] Cron job: wxScintilla is pending approval

[Francesco <fr...@us...>]

name: wxScintilla
wxversion: 
category: gui
language: cpp
description: wxScintilla is a wrapper around the Scintilla edit control (see
http://www.scintilla.org). It's derived from wxStyledTextCtrl done by Robin Dunn.

location: wxscintilla
cdate: 0000-00-00
id: 66
status: stable
docs: notavailable
buildsys: 
extdep: 
wiki: disabled
wxport: 
samples: 0
approved: 0
author: Otto Wyss
version: 1.64.0
mantainerid: 8

[wxCode-users] Cron job: wxTreeListCtrl is pending approval

[Francesco <fr...@us...>]

name: wxTreeListCtrl
wxversion: 
category: gui
language: cpp
description: A tree list control presents information as a hierarchy, with items that may be expanded to show further items. Items in a tree list control are referenced by wxTreeItemId handles, which may be tested for validity by calling wxTreeItemId::IsOk.
location: treelistctrl
cdate: 2004-12-23
id: 65
status: stable
docs: notavailable
buildsys: 
extdep: 
wiki: disabled
wxport: 
samples: 0
approved: 0
author: Otto Wyss
version: 1.02004-12-23
mantainerid: 8

[wxCode-users] Cron job: wxspellchecker is pending approval

[Francesco <fr...@us...>]

name: wxspellchecker
wxversion: 2.4,2.5,2.6,cvs
category: gui
language: cpp
description: wxSpellChecker is an library that provides an API to use various spell checker engines through wxWidgets classes or a C interface.  The developer should have flexibility in the dialog design (using XML resources) and the spell checking interface (only Aspell and Myspell are supported at this time).  For maximum control, developers can derive dialog classes from wxSpellCheckDialogInterface and create more customized dialogs.  Non-dialog based interfaces can be created by deriving from the wxSpellCheckUserInterface directly.  Also support can be added for more spell check engines as needed using the wxSpellCheckEngineInterface base class.
location: wxspellchecker
cdate: 0000-00-00
id: 67
status: stable
docs: hand
buildsys: makefiles,projectfiles
extdep: Aspell (optional)
wiki: disabled
wxport: wxmsw,wxgtk
samples: 1
approved: 0
author: Joe Blough
version: 1.0
mantainerid: 9

Re: [wxCode-users] Website remarks

[Francesco M. <f18...@ya...>]

Hi,

    I've just completed the new viewmode "as single table"; I also did 
some important modification to the log in system which however still 
needs some last touchs... (however everything is working).

I'm now going to complete the "template" module so that anyone can 
update its component website....
however I have to say that we have 23 registered components in the DB 
and 45 components in the CVS.... they should be registered in the DB but 
I suspect that most of them are unmantained... am I right ?
In this case, should we remove them ?

Francesco



Francesco Montorsi wrote:
> Hi,
> 
> Otto Wyss wrote:
> 
>> Registration: 1. I'm not sure but I thought there's a way to use the 
>> sf login (look in
>> the SF docs).
> 
> no; there's no way to do that... also because SF uses secure HTTP 
> connections (through SSL or HTTPS) while project websites cannot use 
> these things...
> 
> 
>> Add Components: 2. The creation date isn't very useful but the last 
>> file release date or
>> version is. External dependencies aren't used very often, so they should
>> only be mentioned inside the component. Dito category.
> 
> I've replaced the "creation date" field in the component list with 
> "latest version" field... even if the cdate is still a useful info and 
> thus I think it's best to keep it, at least in the DB.
> 
> Instead I think that external dependencies are very important and must 
> be listed: think to all those components which are a "bridge" between 
> two libraries (like wxXml2 which connects libxml2 & wx, or wxScript 
> which connects lua, python, cint, underc & wx); they need various 
> external dependencies.
> 
> And the presence/absence of external dependencies is an important factor 
> when choosing to use or not to use a component...
> 
> Last, I think category will be useful in the search page (which I'm 
> working on). Also it would be more important if we could imagine more 
> component categories and update the DB accordingly...
> 
> 
>> 3. The description should be limited to say 300 chars.
> 
> yes, that could be a good thing; however I'm unsure on how to do it: 
> should I just truncate the description string ?
> Maybe it's best to add "... [more in the component website]" string...
> 
> 
>> 4. I would remove the rest of the fields since the contain most of the
>> time the same infos and can be mentioned within the component. Only the
>> first and the last wxWidgets version makes sense. The last version gives
>> also a hint if a component is still supported.
> 
> wxCode is a site specialized in wx-component hosting: I think we should 
> try to give to the users as much info as possible on the components and 
> provide these info in a standard form: i.e. not force them to search for 
> such info into the component websites & render them on the component 
> list page all with the same format.
> Sure, those info can be mentioned also in the component websites but why 
> shouldn't we keep them in the DB, too ?
> Also, I think I'll remove those redundant info from my component 
> webpages so that it will be easier for me to update those info (using 
> the edit form).
> 
> Think to SF (which is conceptually very similar to wxCode: they both 
> host thirdparty projects): if the project info (status, category, 
> author....) would be removed from the project pages (those which begin 
> with http://sourceforge.net/projects/xxxx) then it would be much more 
> difficult for the user who search Open Source software to understand if 
> he has found something good for him: instead of using the project pages 
> as a preliminary filter he would be forced to search in the single 
> websites... it would be a nightmare (for me at least) !
> 
> 
>> Component list:
>> 5. Without colour (Setting: use always my colour) the list is not easy
>> readable. At least a small line should be drawn between the components.
> 
> the component list is quite coloured; each component table has a grey 
> background & the field values are printed in green... the links have a 
> rollover effect and each component entry is separed from the previous 
> one by a blue heading... why do you say it's without colour ?
> Is your browser CSS-enabled ?
> 
> 
>> 6. Description texts should not be bold nor any infos except the
>> component names.
> 
> fixed;
> 
> 
>>
>> 7. The field names shouldn't be repeated in each component but belong
>> into a header.
> 
> I tried such approach but it made the list horrible because:
> 1) to show a decent number of field we would be forced to make a 
> very-wide complist page and thus the user should be forced to 
> continuosly scroll horizontally the page
> 2) the space would not be used correctly since some rows take much more 
> space (in vertical) than others...
> 
> still I think that a table containing the *very basic* info about 
> components (name, latest version & description) could be useful to have; 
> I'll add it to the view mode next to full & compact.
> 
> 
>> 8. I'd prefer the component's infos were links instead of links at the
>> bottom of each component (analog old list).
> 
> the problem is: in which component info should the wiki link be placed ? 
> also in which component infos should all other links be placed ?
> 
> 
>> 9. I hate paged lists so I always set the count to 99999 but it's still
>> a little anoying.
> 
> I could make cookies also for the complist page so that it remembers 
> your favourite view options....
> 
> Francesco
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar 
> happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by HP,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> wxCode-users mailing list
> wxC...@li...
> https://lists.sourceforge.net/lists/listinfo/wxcode-users
> 

Re: [wxCode-users] Website remarks

[Francesco M. <f18...@ya...>]

Hi,

Otto Wyss wrote:
> Registration: 
> 1. I'm not sure but I thought there's a way to use the sf login (look in
> the SF docs).
no; there's no way to do that... also because SF uses secure HTTP 
connections (through SSL or HTTPS) while project websites cannot use 
these things...


> Add Components: 
> 2. The creation date isn't very useful but the last file release date or
> version is. External dependencies aren't used very often, so they should
> only be mentioned inside the component. Dito category.
I've replaced the "creation date" field in the component list with 
"latest version" field... even if the cdate is still a useful info and 
thus I think it's best to keep it, at least in the DB.

Instead I think that external dependencies are very important and must 
be listed: think to all those components which are a "bridge" between 
two libraries (like wxXml2 which connects libxml2 & wx, or wxScript 
which connects lua, python, cint, underc & wx); they need various 
external dependencies.

And the presence/absence of external dependencies is an important factor 
when choosing to use or not to use a component...

Last, I think category will be useful in the search page (which I'm 
working on). Also it would be more important if we could imagine more 
component categories and update the DB accordingly...


> 3. The description should be limited to say 300 chars.
yes, that could be a good thing; however I'm unsure on how to do it: 
should I just truncate the description string ?
Maybe it's best to add "... [more in the component website]" string...


> 4. I would remove the rest of the fields since the contain most of the
> time the same infos and can be mentioned within the component. Only the
> first and the last wxWidgets version makes sense. The last version gives
> also a hint if a component is still supported.
wxCode is a site specialized in wx-component hosting: I think we should 
try to give to the users as much info as possible on the components and 
provide these info in a standard form: i.e. not force them to search for 
such info into the component websites & render them on the component 
list page all with the same format.
Sure, those info can be mentioned also in the component websites but why 
shouldn't we keep them in the DB, too ?
Also, I think I'll remove those redundant info from my component 
webpages so that it will be easier for me to update those info (using 
the edit form).

Think to SF (which is conceptually very similar to wxCode: they both 
host thirdparty projects): if the project info (status, category, 
author....) would be removed from the project pages (those which begin 
with http://sourceforge.net/projects/xxxx) then it would be much more 
difficult for the user who search Open Source software to understand if 
he has found something good for him: instead of using the project pages 
as a preliminary filter he would be forced to search in the single 
websites... it would be a nightmare (for me at least) !


> Component list:
> 5. Without colour (Setting: use always my colour) the list is not easy
> readable. At least a small line should be drawn between the components.
the component list is quite coloured; each component table has a grey 
background & the field values are printed in green... the links have a 
rollover effect and each component entry is separed from the previous 
one by a blue heading... why do you say it's without colour ?
Is your browser CSS-enabled ?


> 6. Description texts should not be bold nor any infos except the
> component names.
fixed;


> 
> 7. The field names shouldn't be repeated in each component but belong
> into a header.
I tried such approach but it made the list horrible because:
1) to show a decent number of field we would be forced to make a 
very-wide complist page and thus the user should be forced to 
continuosly scroll horizontally the page
2) the space would not be used correctly since some rows take much more 
space (in vertical) than others...

still I think that a table containing the *very basic* info about 
components (name, latest version & description) could be useful to have; 
I'll add it to the view mode next to full & compact.


> 8. I'd prefer the component's infos were links instead of links at the
> bottom of each component (analog old list).
the problem is: in which component info should the wiki link be placed ? 
also in which component infos should all other links be placed ?


> 9. I hate paged lists so I always set the count to 99999 but it's still
> a little anoying.
I could make cookies also for the complist page so that it remembers 
your favourite view options....

Francesco

[wxCode-users] Website remarks

[Otto W. <ott...@or...>]

Registration: 
1. I'm not sure but I thought there's a way to use the sf login (look in
the SF docs).

Add Components: 
2. The creation date isn't very useful but the last file release date or
version is. External dependencies aren't used very often, so they should
only be mentioned inside the component. Dito category.

3. The description should be limited to say 300 chars.

4. I would remove the rest of the fields since the contain most of the
time the same infos and can be mentioned within the component. Only the
first and the last wxWidgets version makes sense. The last version gives
also a hint if a component is still supported.

Component list:
5. Without colour (Setting: use always my colour) the list is not easy
readable. At least a small line should be drawn between the components.

6. Description texts should not be bold nor any infos except the
component names.

7. The field names shouldn't be repeated in each component but belong
into a header.

8. I'd prefer the component's infos were links instead of links at the
bottom of each component (analog old list).

9. I hate paged lists so I always set the count to 99999 but it's still
a little anoying.

O. Wyss

-- 
Development of frame buffer drivers: http://linux-fbdev.sf.net
Sample code snippets for wxWidgets: http://wxcode.sf.net
How to build well-designed applications: http://wyoguide.sf.net
Desktop with a consistent look and feel: http://wyodesktop.sf.net

Re: [wxCode-users] wxTreeListCtrl compiler errors on Sun WS C++ compiler...

[Otto W. <ott...@or...>]

Carl Godkin wrote:
> 
> "treelistctrl.cpp", line 2020: Error: Different types for "?:"
> (wxTreeListItem* and wxTreeItemId).
> "treelistctrl.cpp", line 2034: Error: Different types for "?:"
> (wxTreeListItem* and wxTreeItemId).
> 2 Error(s) detected.
> 
> It's right: they are different types.
> 
Changed, thanks.

O. Wyss

-- 
Development of frame buffer drivers: http://linux-fbdev.sf.net
Sample code snippets for wxWidgets: http://wxcode.sf.net
How to build well-designed applications: http://wyoguide.sf.net
Desktop with a consistent look and feel: http://wyodesktop.sf.net

Re: [wxCode-users] Env Var $(WXCODE) in dsw files

[Otto W. <ott...@or...>]

John Labenski wrote:
> 
> How do people write dsw files to include projects to be build from an
> arbitrary wxCode dir?
> 
> I've tried to set the environment variable
> $(WXCODE)=c:\wxCVS\wxCode\wxCode and then use it like this in a dsw
> file for a project that will link to a number of different libraries.
> 
My environment variable is "$(WXCODE)=d:\Devel\wxCode\components" and it
works fine with this project file "http://cvs.sourceforge.net/viewcvs.py/wyoguide/wyoGuide/editor/build/editor.dsp?view=markup".

O. Wyss

-- 
Development of frame buffer drivers: http://linux-fbdev.sf.net
Sample code snippets for wxWidgets: http://wxcode.sf.net
How to build well-designed applications: http://wyoguide.sf.net
Desktop with a consistent look and feel: http://wyodesktop.sf.net

[wxCode-users] wxTreeListCtrl compiler errors on Sun WS C++ compiler...

[Carl G. <cg...@gm...>]

Hi,

I just fixed a problem on our local version of treelistctrl.cpp that you=20
might want to
apply to the CVS version.

Sun's C++ compiler (CC: Sun WorkShop 6 update 2 C++ 5.3) complains about
two lines:


"treelistctrl.cpp", line 2020: Error: Different types for "?:"=20
(wxTreeListItem* and wxTreeItemId).=20
"treelistctrl.cpp", line 2034: Error: Different types for "?:"=20
(wxTreeListItem* and wxTreeItemId).=20
2 Error(s) detected.=20

It's right: they are different types.

I suggest these changes:

return ((*pIndex)+1 < (long)children.Count())? wxTreeItemId
(children.Item(++(*pIndex))):
wxTreeItemId();

and
return ((*pIndex)-1 >=3D 0)? wxTreeItemId (children.Item(--(*pIndex))):=20
wxTreeItemId();

All I changed was to surround the argument after the "?" with=20
wxTreeItemId().

Thanks,

carl

Re: [wxCode-users] To all dev: wxCode database

[Francesco M. <f18...@ya...>]

Hi,

> I noticed that when you sign up for a wxCode username/password (it
> should be clarified that this only to allow you to adjust the website
> component database and has nothing to do with SF) it says to use
> "@nospam" in your email address. But when you submit it, it happily
> says that it just sent a message to you...@no.... Maybe
> it needs to just add @nospam by itself or even better (but probably
> too hard) make it an image.
you're right: I'll write some clarification in the registration form & 
also modify the script so that the @nospam is added automatically.

> There should also be a way to then edit
> these settings, but maybe I've missed that.
I haven't created a page to modify the mantainer settings since they are 
few and should not change often.
In case you need to modify yours, go to
wxcode.sourceforge.net/phpMyAdmin
I'll mail privately to you & Otto the new database password to use to 
access that page


>>I've completed all pages of wxCode site and now I just need that you all
>>update the DB with your info.
> 
> It looks great, Thanks.  But, ummm, where does it go? Could you put a
> brief note in the readme.txt file about this and needs to be done to
> maintain it. Sorry, I've been very busy the past couple weeks and
> haven't been able to keep up.
Sure; I need to write all mantainance stuff somewhere.. please check the 
other mail I'm sending you.

Francesco Montorsi

Re: [wxCode-users] Cron job: wxSheet is pending approval

[Francesco M. <f18...@ya...>]

I set the component as approved; the cron job for mailing now works ;-)

FM

Francesco wrote:
> name: wxSheet
> wxversion: 2.6
> category: gui
> language: cpp
> description: wxSheet is a spreadsheet type grid widget for the wxWidgets GUI library. The wxSheet code is based on the wxWidget's wxGrid class and is, for the most part, a complete rewrite, almost every function has been tweaked. It is not backwards compatible, but is logically similiar. Many of the functions have the same names and you can expect them to perform a similiar task, but the parameters may be different. The reason for creating a completely separate grid implementation is to allow far more control over the different aspects of the operation either though subclassing or intercepting events. You will find documentation included in the header files with the member functions ordered by function. You can of course look under the hood, at the cpp files, to fully understand what each function does. I welcome any changes or interesting ideas you may have for improvement.
> location: wxsheet
> cdate: 2006-07-20
> id: 62
> status: stable
> docs: hand
> buildsys: makefiles,projectfiles
> extdep: 
> wiki: disabled
> wxport: wxmsw,wxgtk
> samples: 1
> approved: 0
> author: John Labenski
> version: 1.0
> mantainerid: 7
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> wxCode-users mailing list
> wxC...@li...
> https://lists.sourceforge.net/lists/listinfo/wxcode-users
> 

[wxCode-users] Cron job: wxSheet is pending approval

[Francesco <fr...@us...>]

name: wxSheet
wxversion: 2.6
category: gui
language: cpp
description: wxSheet is a spreadsheet type grid widget for the wxWidgets GUI library. The wxSheet code is based on the wxWidget's wxGrid class and is, for the most part, a complete rewrite, almost every function has been tweaked. It is not backwards compatible, but is logically similiar. Many of the functions have the same names and you can expect them to perform a similiar task, but the parameters may be different. The reason for creating a completely separate grid implementation is to allow far more control over the different aspects of the operation either though subclassing or intercepting events. You will find documentation included in the header files with the member functions ordered by function. You can of course look under the hood, at the cpp files, to fully understand what each function does. I welcome any changes or interesting ideas you may have for improvement.
location: wxsheet
cdate: 2006-07-20
id: 62
status: stable
docs: hand
buildsys: makefiles,projectfiles
extdep: 
wiki: disabled
wxport: wxmsw,wxgtk
samples: 1
approved: 0
author: John Labenski
version: 1.0
mantainerid: 7

[wxCode-users] Cron job: wxSheet is pending approval

[Francesco <fr...@us...>]

name: wxSheet
wxversion: 2.6
category: gui
language: cpp
description: wxSheet is a spreadsheet type grid widget for the wxWidgets GUI library. The wxSheet code is based on the wxWidget's wxGrid class and is, for the most part, a complete rewrite, almost every function has been tweaked. It is not backwards compatible, but is logically similiar. Many of the functions have the same names and you can expect them to perform a similiar task, but the parameters may be different. The reason for creating a completely separate grid implementation is to allow far more control over the different aspects of the operation either though subclassing or intercepting events. You will find documentation included in the header files with the member functions ordered by function. You can of course look under the hood, at the cpp files, to fully understand what each function does. I welcome any changes or interesting ideas you may have for improvement.
location: wxsheet
cdate: 2006-07-20
id: 62
status: stable
docs: hand
buildsys: makefiles,projectfiles
extdep: 
wiki: disabled
wxport: wxmsw,wxgtk
samples: 1
approved: 0
author: John Labenski
version: 1.0
mantainerid: 7

[wxCode-users] Cron job: wxSheet pends approval

[Francesco <fr...@us...>]

name: wxSheet
wxversion: 2.6
category: gui
language: cpp
description: wxSheet is a spreadsheet type grid widget for the wxWidgets GUI library. The wxSheet code is based on the wxWidget's wxGrid class and is, for the most part, a complete rewrite, almost every function has been tweaked. It is not backwards compatible, but is logically similiar. Many of the functions have the same names and you can expect them to perform a similiar task, but the parameters may be different. The reason for creating a completely separate grid implementation is to allow far more control over the different aspects of the operation either though subclassing or intercepting events. You will find documentation included in the header files with the member functions ordered by function. You can of course look under the hood, at the cpp files, to fully understand what each function does. I welcome any changes or interesting ideas you may have for improvement.
location: wxsheet
cdate: 2006-07-20
id: 62
status: stable
docs: hand
buildsys: makefiles,projectfiles
extdep: 
wiki: disabled
wxport: wxmsw,wxgtk
samples: 1
approved: 0
author: John Labenski
version: 1.0
mantainerid: 7

[wxCode-users] Component submission

[Francesco <fr...@us...>]

[wxCode-users] Component submission

[Francesco <fr...@us...>]

[wxCode-users] Component submission

[Francesco <fr...@us...>]

[wxCode-users] Component submission

[Francesco <fr...@us...>]

[wxCode-users] Component submission

[Francesco <fr...@us...>]

[wxCode-users] Component submission

[Francesco <fr...@us...>]

Re: [wxCode-users] To all dev: wxCode database

[John L. <jla...@gm...>]

On 7/5/05, Francesco Montorsi <f18...@ya...> wrote:
>     since the HTTP basic authentication was quite ugly; I decided to use
> a pure PHP authentication.
> The usernames & passwords of wxCode mantainers are now stored in the
> wxCode 'mantainers' table.

I noticed that when you sign up for a wxCode username/password (it
should be clarified that this only to allow you to adjust the website
component database and has nothing to do with SF) it says to use
"@nospam" in your email address. But when you submit it, it happily
says that it just sent a message to you...@no.... Maybe
it needs to just add @nospam by itself or even better (but probably
too hard) make it an image. There should also be a way to then edit
these settings, but maybe I've missed that.
=20
> I've completed all pages of wxCode site and now I just need that you all
> update the DB with your info.

It looks great, Thanks.  But, ummm, where does it go? Could you put a
brief note in the readme.txt file about this and needs to be done to
maintain it. Sorry, I've been very busy the past couple weeks and
haven't been able to keep up.

Regards,
    John Labenski

Re: [wxCode-users] Env Var $(WXCODE) in dsw files

[John L. <jla...@gm...>]

> which VS version are you using ?
> I created a file (by hand) name wxsheet.dsw with the contents:
> =3D=3D=3D=3D=3D=3D=3D=3Dwxsheet.dsw=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Microsoft Developer Studio Workspace File, Format Version 6.00
> Project:
> "wxSheetLib_wx26"=3D$(WXCODE)\components\wxsheet\src\sheetlib_wx26.dsp -
> =3D=3D=3D=3D=3D=3D=3D=3Deof=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
>=20
> and with MSVC++ 6.0 it opens up perfectly with WXCODE=3Dt:\wxCode (my pat=
h
> to the wxCode folder)....

Yeah, I use 6 too. I've made sure to have deleted all the files
created by MSVS in all the project dirs. I wonder if it's trying to be
clever and storing some info elsewhere. Well, I'm glad to hear it
works even if not on my system. I'll keep beating on it.
=20
> another advice is: use bakefile to generate your DSW/DSP files ;-)

Heh. Someday...
=20
> I have removed the x flag from non-scripts file; However I also need to
> have write permissions on the "template" folder of the wxCode CVS.
> The file CVSROOT\avail needs to be modified to allow me to work on
> wxCode\template and only you & Otto can do that...

Done.
=20
> For more info about "template" see
> http://wxcode.sourceforge.net/rules.php, rule #1
>=20
> It will contain all the usual stuff & folder structure of a typical
> component...

Ok.

Regards,
    John Labenski