wysiwyg?

[DJMaze]

What about a implementation of WYSIWYG?
Let's say you build a window in wxWidgets, C::B loads the library (already loaded anyway) and creates the window based on the window position, size and settings.

Not so sophisticated as MSVC or BCB but more like a simple preview or make it just as sophisticated by using a new file type '.wxd' (wxWidgets Designer) and '.fld' (FLTK Designer) and the designer file contains the position and size data.

[takeshimiya]

What about a implementation of WYSIWYG?
Let's say you build a window in wxWidgets, C::B loads the library (already loaded anyway) and creates the window based on the window position, size and settings.

Not so sophisticated as MSVC or BCB but more like a simple preview or make it just as sophisticated by using a new file type '.wxd' (wxWidgets Designer) and '.fld' (FLTK Designer) and the designer file contains the position and size data.

I'm not sure I understand what you want to do, but I wonder, that's what wxSmith does (for wxWidgets), isn't?
And for FLTK, that's what fluid does.

Or you're talking not about a RAD but something different, not ever done before on any existing app?

[DJMaze]

yes, similar to fluid and wxSmith but then integrated inside C::B as wysiwyg plugins or something.

fluid and wxSmith are form designers only but, as somesort of plugin inside C::B you have the power of both (code editor and form designer). This way you can increase development speed just like RAD but do not make it a full RAD since that will limit flexibility.

I was more thinking about a structure like Borland's VCL. You compile widgets into a library and C::B loads these libraries. Then you can drop widgets on a form like in fluid and wxSmith and the code designer puts the needed C++ code inside the .cxx file.

That way you can rapidly design a form inside C::B but without loosing control.

RAD Example:
say in fluid you design a window with buttons, select box and richedit. After that you must select the menu option to write the code to a file so you can alter it.

C::B Example:
you design a window with buttons, select box and richedit and while you're dropping the widgets on the form C::B instantly writes the equivelant code into the .c and .h files.

1. The menu has a new option "new window" that starts a wizard to select what kind of window you want (fluid, wxWidgets, etc.) and how you want the filename.
2. Click OK and C::B writes a filename.cxx and filename.h and then opens the files and a form designer
3. (Lets say below the menu)  a tabs section pops up which contains widgets.
4. select a widget and drop it on the form designer
5. when dropped C::B writes the needed code in the .c and .h files
6. modify the .c and .h files yourself to get the effect you want.

A real RAD/wysiwyg needs another file, as i explained above, so that it doesn't have to read your .c and .h files to figure out what you realy want.

I hope i made myself clear about the difference between fluid/wxSmith and a system inside C::B

[thomas]

fluid and wxSmith are form designers only but, as somesort of plugin inside C::B you have the power of both (code editor and form designer). This way you can increase development speed just like RAD but do not make it a full RAD since that will limit flexibility.

I was more thinking about a structure like Borland's VCL. You compile widgets into a library and C::B loads these libraries. Then you can drop widgets on a form like in fluid and wxSmith and the code designer puts the needed C++ code inside the .cxx file.

That way you can rapidly design a form inside C::B but without loosing control.

I begin to wonder if you have ever actually used Fluid (or wxSmith). This is exactly how it works...

[DJMaze]

I begin to wonder if you have ever actually used Fluid (or wxSmith). This is exactly how it works...

OK i think you didn't get it. In fluid you can design forms but after that you must call in the menu "File" -> "write code"
The issue here is, after you wrote the code and modify it but think "hmm i need another widget on the form" you're screwed since you call "File" -> "write code" again and all your changes are lost, unless you run a merger app or something.

Instead, thru C::B you can instantly add a new widget to a form without loosing changes AND you can modify the code instantly.

For example you have a new form and write code to the .c file to take certain actions on the form.
After that you add a button widget and write additional code for the widget.
Then you add another button and write code for it.

Did you ever use Borland C++ Builder/Delphi/Kylix or MS VC++ Studio ?

NOTE: i use FLTK 2

[thomas]

The issue here is, after you wrote the code and modify it but think "hmm i need another widget on the form" you're screwed since you call "File" -> "write code" again and all your changes are lost, unless you run a merger app or something.

But... you don't modify that code. You never do.
If you need to add custom code to those widgets, you do that from inside the RAD (and save it with the RAD project). Then you can always add or remove widgets or do whatever, and use "write code" as often as you like. wxSmith even does all the nasty event stuff for you.

The rest of your app is widely independent of all of that, anyway (or should be).

Maybe I really don't understand the problem, but I think that it does just what you want :lol:

[DJMaze]

If you need to add custom code to those widgets, you do that from inside the RAD (and save it with the RAD project).

That's my whole point: don't save it with the RAD, but save it in .cxx file.

If you have never used a Borland IDE i will wrap up some screenshots to show what i mean

[takeshimiya]

If you need to add custom code to those widgets, you do that from inside the RAD (and save it with the RAD project).

That's my whole point: don't save it with the RAD, but save it in .cxx file.

If I understand what you mean, it would be the same as "saving .cbp projects embedded in .cxx" (!).
Some sort of project management is always necessary.

Another thing: wxSmith generates the code and the widgets in the .cxx files, so I really don't understand what you're saying. Or, you never used it?

Anyways using XRC files instead of widgets embedded in the .cxx source is always preferred whenever available.

If you have never used a Borland IDE i will wrap up some screenshots to show what i mean

Yes, please do, because I really don't get what you're trying to explain.

[mandrav]

If you need to add custom code to those widgets, you do that from inside the RAD (and save it with the RAD project).

That's my whole point: don't save it with the RAD, but save it in .cxx file.

If you have never used a Borland IDE i will wrap up some screenshots to show what i mean

Are you sure you know how to use wxSmith?
Read this please...

[byo]

DJMaze, maybe I'll jsut clarify how wxSmith does work and what I've wanted to do from the very beginning.

wxSmith is a RAD tool what means it can write lot of annoying code for You. It generates it on-the-fly, each change inside editor affects some .cpp / .h files. But it does not create the file from scratch (it does it just at the beginning, only once to create some skeleton).
When You look into source code generated with wxSmith There are some parts which are recreated and some which are left untouched. That was the goal - You can freely add Your own members to classes, change names, add Your own event handlers etc. And as long as You put it outside regenerated parts You won't loose it.
And how does wxSmith know what parts of source code it should recreate ?
Blocks of recreated code are marked with special comments. Each block MUST start with //(* and end with //*).
wxSmith does use comments for marking parts of code which need to be recreated. Other tools use some simillar techniques (latest visual studio use #pragma for that, Borland uses AFAIK published class section).
It could be also done with parsing class and analyzing it's content but it's really hard to do - If You don't believe just read some articles on C++ parsing.

When You use wxSmith You can work on both RAD designer and source code. As long as You don't remove nor change wxSmith-generated code it's safe to do.

[DJMaze]

I don't use wxSmith since i don't use wxWidgets for my projects.

If you say that wxSmith does write the files like the better known IDE's then its fine by me.
My point was more to have it embedded inside code::blocks



Let's say the red parts are wxSmith but then as C::B plugin.
Then if you add/modify/delete stuff it updates instantly inside C::B

It could be also done with parsing class and analyzing it's content but it's really hard to do - If You don't believe just read some articles on C++ parsing.

I know this will be hard but that's not what i ment.

Borland uses .dfm files. These files only contain the class instance details like width, height, position, method assignments and children.

Code

object Form1: TForm1
  Left = 192
  Top = 107
  Width = 696
  Height = 480
  Caption = 'Form1'
  Color = clBtnFace
  Font.Charset = DEFAULT_CHARSET
  Font.Color = clWindowText
  Font.Height = -11
  Font.Name = 'MS Sans Serif'
  Font.Style = []
  OldCreateOrder = False
  PixelsPerInch = 96
  TextHeight = 13
  object Label1: TLabel
    Left = 8
    Top = 40
    Width = 32
    Height = 13
    Caption = 'Label1'
  end
  object Button1: TButton
    Left = 8
    Top = 8
    Width = 75
    Height = 25
    Caption = 'Button1'
    TabOrder = 0
    OnClick = Button1Click
  end
end

Something similar to that inside c::b would eliminate the overwrite when you change something inside the RAD.
Since the only thing that has to be done is lookup the .c/.h files if the new method, for example, exists or has to be created.

The content of this .dfm file is nothing more then an easy layout of the class constructor or main() function.

It's not something i will use today but when i started coding for the first months this kind of RAD development as provided by Borland just realy made it easy for me to start developing since i didn't have to care how to create a window and put a button on it.
The other benefit was that i wrote it all in one go thru a single IDE without having to worry about loading and saving the correct version of a file between several applications.
So if wxSmith/fluid are available as C::B plugins it would make this IDE very popular for starters.

[takeshimiya]

This is sufficient?

wxSmith is a Code::Blocks plugin for RAD editing of wxWidgets applications.

It's being developed by byo, and co-developed by cyberkoa.

It can be downloaded from http://codeblocks.org

[DJMaze]

almost, i've read about it and understood it.

So i see wxSmith does the job for wxWidget programming, but what about others like FLTK, GTK and Qt ?
Can't there be somesort of "connector" that lets any RAD tool communicate with the source files?

For example i wrote my own toolkit and instruct C::B to add/replace/edit a string inside a file

[takeshimiya]

almost, i've read about it and understood it.

So i see wxSmith does the job for wxWidget programming, but what about others like FLTK, GTK and Qt ?
Can't there be somesort of "connector" that lets any RAD tool communicate with the source files?

Yes, it's called Code::Blocks SDK.

You are very welcomed to write a "connector" for other toolkits like FLTK, GTK and QT.
AFAIK, there are some works on getting more integrated with QT designer (don't remember who exactly).

For example i wrote my own toolkit and instruct C::B to add/replace/edit a string inside a file

Something to made that more easier for you, would depend on a C++/other languages full AST parsed of the source code, if you want it to be easy, that is, but it's not feasible for now, as byo pointed out parsing C++ is hell.

But a very easy solution would be to use regex based parsing.
Look at how it does the Code::Blocks "ToDo plugin". :wink:

[rickg22]

In theory, wxSmith should excel in generating and editing XRC files, which are XML representations of widgets (they'd be your equivalent of DFM files), and the C++ only loads the widgets using the XRC library in wxWidgets. Unfortunately, (the last time i used wxSmith) most of the work done is about dealing with generated C++ code.