Author Topic: wxSmith development  (Read 122627 times)

Offline cyberkoa

  • Plugin developer
  • Almost regular
  • ****
  • Posts: 145
    • http://
wxSmith development
« Reply #45 on: May 28, 2005, 07:13:10 pm »
Quote from: byo
Quote from: cyberkoa
Thx,understood.  The flag indicate whether the widget is static widget (keep in xrc) or dynamics created using C++ code . Hmm ,this is important in code generation.


Hmm, not exackly. The flag indicating whether dialgo uses XRC or should be inside dialog resource, not one widget.

Maybe will describe with a bit of code (example what would be generated from wxSmith;) ):

1). One widget with VarNotStored = false
Code: [Select]
class MyDialog: public wxDialog
{
  public:
    MyDialog(...)
    {
      Widget = new wxStaticText(this,-1,"Hello world");
    }
  protected:
    wxStaticText* Widget;
}


2). One widget with VarNotStoredd = true
Code: [Select]
class MyDialog: public wxDialog
{
  public:
    MyDialog(...)
    {
      wxStaticText* Widget;
      Widget = new wxStaticText(this,-1,"Hello world");
    }
}


So if VarNotStored == true, it means that Variable for this widget will be created locally inside function creating dialog, VarNotStored == false means that it will be a member of class and will be acessible from other members in this class.

Hope I've explained this now :)


Ok, totally understand. I think the best language to communicate among programmers is computer language  :lol:   :lol:

Quote from: rickg22
Uh... shouldn't you change the name to IsMember or something?


A good recommentation, I think.

Anonymous

  • Guest
wxSmith development
« Reply #46 on: May 31, 2005, 07:34:40 pm »
Quote
So if VarNotStored == true, it means that Variable for this widget will be created locally inside function creating dialog, VarNotStored == false means that it will be a member of class and will be acessible from other members in this class.

Isn't the local variable still available to other member functions due to the "this" linkup (just not as a member)?  Otherwise, the var would be an invalid memory location--as it is released at the end of the function automatically (scope, delete is implied)--and the active dialog would continue pointing to these released memory locations (it doesn't since the pointer's reference counter > 0).  Isn't there a mechanism to step throught the widgets of a window?  Or is "VarNotStored" simply a way to separate direct access to widgets from indirect access, so that the programmer can concentrate on the direct items?
I agree the "isMember" might be a better var name.

Offline DreadNot

  • Multiple posting newcomer
  • *
  • Posts: 47
    • http://www.utdallas.edu/atescomp
wxSmith development
« Reply #47 on: May 31, 2005, 07:36:51 pm »
Above was mine.
There are two ways to code: watertight & bulletproof!

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 837
wxSmith development
« Reply #48 on: May 31, 2005, 10:09:22 pm »
Quote from: Anonymous
Isn't the local variable still available to other member functions due to the "this" linkup (just not as a member)?  Otherwise, the var would be an invalid memory location--as it is released at the end of the function automatically (scope, delete is implied)--and the active dialog would continue pointing to these released memory locations (it doesn't since the pointer's reference counter > 0).  Isn't there a mechanism to step throught the widgets of a window?  Or is "VarNotStored" simply a way to separate direct access to widgets from indirect access, so that the programmer can concentrate on the direct items?
I agree the "isMember" might be a better var name.


Hmm these variables will be actually pointers to real widgets. And these widgets could be later found through FindWindow() or something like this.

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 837
wxSmith development
« Reply #49 on: May 31, 2005, 10:13:19 pm »
Hmm, and another thing.
I currently have hard times during my study (need to pass all these exams etc. etc. ) so wxSmith won't be updated regularly :(
Hope You  won't be angry  :oops:

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
wxSmith development
« Reply #50 on: June 01, 2005, 01:13:29 am »
hehe lol :P Don't worry byo! School must always go first. Open source is a HOBBY (Blasphemy! :shock: lol :lol: )

Offline upCASE

  • Multiple posting newcomer
  • *
  • Posts: 16
    • http://www.upcase.de
wxSmith development
« Reply #51 on: June 01, 2005, 08:24:17 am »
Hi!
Quote from: byo
Hmm, and another thing.
I currently have hard times during my study (need to pass all these exams etc. etc. ) so wxSmith won't be updated regularly :(
Hope You  won't be angry  :oops:

Don't worry: It doesn't get any better -> Next there comes a job  :D
Anyway: Good luck for your exams!

BTW: About the icons I used in wxRapid, I have to confess I snatched them from wxGlade  :oops:
OS: Win XP Pro, Linux, Mac, CE
wx: 2.6.0
Compiler: VC 7.1, gcc 3.4.2, eVC 4  - If it was hard to write it should be hard to read... - Try not! Do. Or do not. There is no try.

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
wxSmith development
« Reply #52 on: June 01, 2005, 06:44:03 pm »
upCASE: Any copyrighting problem with those? Should we add a license regarding the icons or something?

Offline David Perfors

  • Developer
  • Lives here!
  • *****
  • Posts: 560
wxSmith development
« Reply #53 on: June 01, 2005, 07:23:17 pm »
I don;t think there is a copyright problem, because wxGlade is open source to. just mention the name some where in a file and you ar finished (I didn't look in the license of them yet.)
OS: winXP
Compiler: mingw
IDE: Code::Blocks SVN WX: 2.8.4 Wish list: faster code completion, easier debugging, refactoring

Offline DreadNot

  • Multiple posting newcomer
  • *
  • Posts: 47
    • http://www.utdallas.edu/atescomp
wxSmith development
« Reply #54 on: June 01, 2005, 10:16:08 pm »
I'm git'n school'ed here too!
But, I believe this project is sooo very important as open source due to the lack of alternatives in other IDEs.
I'll be studying this project and hopefully be contributing over time.

Thanks for answering the question.  I made a mistake on the implied delete operator.  The delete is not implied at the end of the function--I was thinking "auto_ptr", which is not necessary. From the wxWidgets site, I understand how the memory is released for the widgets through the parent-child relationship and the close event handler.

Please excuse my ignorance if this is obvious to others as I'm new to wxWidget and unfamiliar with the specifics on memory allocation / deallocation on these object.
There are two ways to code: watertight & bulletproof!

Offline cyberkoa

  • Plugin developer
  • Almost regular
  • ****
  • Posts: 145
    • http://
wxSmith development
« Reply #55 on: June 02, 2005, 01:04:19 am »
the student nowadays is very expert in C++ ! 8)

I am studing the wxSmith source code. byo , if you do not mind , I shall try to write some code on the defwidget for combobox , meaning add in additional widget option and submit those code to you for checking. If you feel that it is helpful , you may modify and commit to CVS . However, I have to mention earlier , I have just start using C++ a few months ago after 6 years never touching it until I  found the wxwidgets.

Offline DreadNot

  • Multiple posting newcomer
  • *
  • Posts: 47
    • http://www.utdallas.edu/atescomp
wxSmith development
« Reply #56 on: June 02, 2005, 09:33:48 am »
I've review the latest wxSmith.  There was some question about the display for properties a while back.  Other than not emulating VC++, why not model the display on VC++ and use a row and column style display (wxGrid with wxGridCell... types) where row labels are the property name and the column displays the value(s) with an elipse button [don't know how to do] on items that expand to dialogs when more info is required or multiple selection are required (like style parameters), combobox selections for mutually exclusive items, and true/false combobox selections to replace checkboxes.  This could:
1) allow the user to size the rowlabel and value columns removing concern about long labels and
2) let us setup the parameter display using a single standard resource for all widget types (a constant boolean array for each widget type would specify the parameters to display and record, another array could represent default values for each parameter).
There are two ways to code: watertight & bulletproof!

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 837
wxSmith development
« Reply #57 on: June 02, 2005, 11:56:17 pm »
Quote from: cyberkoa
the student nowadays is very expert in C++ ! 8)

I am studing the wxSmith source code. byo , if you do not mind , I shall try to write some code on the defwidget for combobox , meaning add in additional widget option and submit those code to you for checking. If you feel that it is helpful , you may modify and commit to CVS . However, I have to mention earlier , I have just start using C++ a few months ago after 6 years never touching it because I  found the wxwidgets.


Hmm, Waiting for Your job :). But must say that some parts of code are not finished yet (f.ex. events sytem) and update of this code will be needed soon :).

Thx for Your interesting. Hmm, One of my idedas was to create RAD tyool which could be easily extended with new sets of widgets :).

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 837
wxSmith development
« Reply #58 on: June 03, 2005, 12:00:29 am »
Quote from: DreadNot
I've review the latest wxSmith.  There was some question about the display for properties a while back.  Other than not emulating VC++, why not model the display on VC++ and use a row and column style display (wxGrid with wxGridCell... types) where row labels are the property name and the column displays the value(s) with an elipse button [don't know how to do] on items that expand to dialogs when more info is required or multiple selection are required (like style parameters), combobox selections for mutually exclusive items, and true/false combobox selections to replace checkboxes.  This could:
1) allow the user to size the rowlabel and value columns removing concern about long labels and
2) let us setup the parameter display using a single standard resource for all widget types (a constant boolean array for each widget type would specify the parameters to display and record, another array could represent default values for each parameter).


http://www.geocities.com/jmsalli/propertygrid/ - it has already been done i think :). But need to wait for compatibility with wx 2.6. Hmm, maybe it has already been done, haven't read forum for some time  :oops:

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
wxSmith development
« Reply #59 on: June 03, 2005, 12:44:09 am »
Dunno, we need some brave warrior who dares compile C::B CVS with wx2.6. Thou shalt slay the red bug dragon! :P