I tried the new version and I must say that it runs more stable for me than the old version with newest nightlies. The old version started to crash in many situations with newer Codeblocks versions. I'm using windows.
It certainly is a great improvement over the old version.
One bug I noticed where drawing fragments outside of the current frame. Meaning when for example you remove a control the total size of a frame shrinks in the preview. The frame is correctly drawn however the regions that now lies outside of the frame are not correctly cleared to the background color. This happens in numerous situation so you probably already know about it.
Create a new project and then add a wxSmith frame. In the project manager (that window where you can browse your source files and code completion symbols) go to the "Resources" tab. In the tree you will see a root named "Resources" below it an unnamed element which is the root for all wxSmith resources.
Another more serious bug happens when you often change a sizer property of a control. I tried changing the expand flag check box in both the regular property tab and in the quick property panel and I changed the border size using the increase and decrease buttons in the quick property panel. I clicked the buttons fast about a 50 times. I don't know if the error also happens when pushing them slowly after another. After a number of clicks the drawing starts to lag. I looks like if it remembered all the previous states (undo level?) and would draw then first before drawing the final state. When now exiting Codeblocks you might get lucky and nothing happens or it just crashes but most of the time the following assertion is triggered:
File: wxscoder.cpp
Line: 39
Expression: EM != NULL
When toggling the "Is member" check box the preview frame is redrawn. This is not necessary.
When adding a bitmap button and loading the image from a file the following code is generated:
wxSize StaticBitmap1_Size = wxDefaultSize;
StaticBitmap1 = new wxStaticBitmap(this,ID_STATICBITMAP1,wxBitmap(_("..."));
,wxDefaultPosition,StaticBitmap1_Size,0,_T("ID_STATICBITMAP1"));
Obviously one ";" is too much.
http://www.wxwidgets.org/manuals/2.6.3/wx_wxbitmap.html#wxbitmapctor
Under Windows, type defaults to wxBITMAP_TYPE_BMP_RESOURCE. Under X, type defaults to wxBITMAP_TYPE_XPM.
However we want to read an image from a file so that wont work. I don't know how you can make it so that wxWidgets loads a file and auto-detects the type so I'd suggest looking at the extension and then passing wxBITMAP_TYPE_BMP/wxBITMAP_TYPE_GIF/... as second parameter. Perhaps even adding an option to the bitmap selector dialog to indicate the type if for example the files have non standard extension or even wrong extensions.
Also the bitmap selector dialog crops the bitmap down in the preview, perhaps shrinking would be a better options. Also it is currently not possible to load resources. (It would be great if wxSmith or another plugin could manage those.)
I didn't quiet understand how the font selector dialog works, is it already fully functional? Anyway it might be a good idea to allow the user to specified the example text (well he'll see how it looks in the preview anyway so it might not be a so good idea after all). Anyway you're using wxSystemSettings::GetFont but didn't include <wx/settings.h>.
When removing controls the corresponding headers are no longer included. However it's possible that these headers provided the declarations for the events of some handlers. The easiest fix would be to include the needed headers outside of the //(*Headers(...)//*) tags when a handler is added. This way they are included twice and when the control is removed the version outside of the //(*Headers(...)//*) tags is still there.
When adding a StdDialogButtonSizer and adding ok and yes buttons they are placed over another. (This might be wx bug and not a wxSmith one.)
By changing the wxSP_3D style of a wxSplitterWindow the preview window give the splitter too much space. The space for the border is there but it isn't used as I have unset wxSP_3D. Perhaps move wxSplitterWindow to the layout category.
That's all I could find for bugs. However I would have a few suggestions.
In the regular property editor some can have only a predefined number of values. (For example "Horizontal align" can only have 3 values.)
Delphi changed the value to the next in the list when just double clicking (no need to select in the drop down box). I found that pretty handy.
Make the delete key delete the currently selected control.
By default make controls expand.
I really loved how under Delphi double clicking a button in the preview generated the click handler and scrolled to the right position in the source code. Perhaps add a line:
when generating a handler so that it's possible to scroll to the right place by just double clicking the control in the preview.
Add some possibility to move controls around in the tree and not only in the preview. Make it possible to move sizers around with all the controls they contain.
Allow to specify the creation code for custom widgets somewhere centrally. You add a new control to a list then add the creation code, the name and specify a bitmap which will be used to fill out the region in the preview.
Anyway even if it still needs some polishing wxSmith is already great as it is. Keep up the good work.
Please put back in the popup showing when that the wxsmith version is expreimental and not for production purpose. One knew the moment one started Code Blocks that the extension was correctly installed. ;)
Bugs:
- When selecting a non wxsmith tab in the editor (such as for example a *.cpp file) then going into the resource tree and double clicking on a frame will bring the *.wxs to the front in the editor. However this does not work if you double click any of the sub widgets of a frame such as for example a button.
- When deleting the last subwidget of a box sizer the sub widget is deselected in both resource tree and preview window. Then it is deleted. Now nothing is selected in the preview window. In the resource tree the sizer gets a different background color (However a third one different from not selected and explicitly selected). Clicking on the sizer in the resource tree will make the back color change to "selected" in the tree but it will not be selected in the preview. It is not possible to add any widgets to the sizer. The solution is to either select the sizer in the preview or select something different in the tree and then select sizer again in the tree.
- In the property tab the new font element is simpler to use in my opinion than the old. However there is a bug : The font property is mad up of a tree : root with a name that resumes the settings. 2 childes one being a check box defining if a non default font should be used an another sub tree with the non default font details. The problem is that the name of the root element is editable. Editing it wont hurt as it is always automatically reset to the previews state but perhaps it might be better to make it non editable. Also if the default font is used then it might be a better idea to change the whole description to "default font" instead of "FALSE [... a lot of not used stuff...]".
- There's a probably hard to solve problem with the bitmap buttons (or any bitmap resource) in combination with the MinGW compiler and non English Windows versions (probably also non English Linux but didn't try). Files or path may contain non standard characters such as "èéäößê". The code is generated correctly. However it wont compile with the following error:
converting to execution character set: Illegal byte sequence
Probably only 7bit ANSI characters are allowed in string literals but I haven't tested it.
- When a wxBitmap widget with a bigger image than the working area is created or moved the preview window is not correctly updated when scrolled. This does not happen if the widget hasn't been recently changed.
- wxSplitterWindow also doesn't always correctly distribute its client area between its childs:
(http://img77.imageshack.us/img77/5471/wxsbug1kr6.png)
I don't know under which circumstances this happens however I could produce it fairly often unwillingly so you should be able to reproduce it by playing around with the control. Also I think that wxSplitterWindow is more a sizer than a control so I'd place it under the Layout tab with all the other sizers.
- Under Windows when moving another window of another program over the preview window then it's always completely updated and flashes quiet a bit. Nothing serious but you might consider limiting the redraws per second.
Bug with "EM != NULL" assertion - I've never got this so I couldn't find the reason of this failure
I can't reproduce it either with the new version. Probably it was caused by the same code which caused the fragments.
Toggling "Is Member" and changing few other properties still cause editor to refresh (it would require some bigger changes in property system so maybe in future). Since there's no blinkink bug, it should not be frustrating
No it's not frustrating at all. Just wanted to point it out. ;)
Problem with headers for handler functions - this will be quite hard to fix (need to parse handlers list, check what headers are required for handler arguments). Fortunately as long as pch is used, absent headers are no problem
I think you didn't understand what I suggested. You have for example the following code:
//(*Headers(NewFrame)
#include <wx/textctrl.h>
#include <wx/button.h>
#include <wx/frame.h>
//*)
Now I add a wxTextCtrl only handler. Meaning one which needs an event defined in that header. Now change the header code to the following:
#include <wx/textctrl.h>
//(*Headers(NewFrame)
#include <wx/textctrl.h>
#include <wx/button.h>
#include <wx/frame.h>
//*)
Doesn't look great but when the wxTextCtrl is removed you are left with
#include <wx/textctrl.h>
//(*Headers(NewFrame)
#include <wx/button.h>
#include <wx/frame.h>
//*)
and the code still compiles.
Replaced previous font editor with simplified dialog (previous editor is available under advanced options)
Where are those advanced options?
Anyway the new version ran pretty stable and didn't crash.
I was patching code in prep for testing wxWidgets 2.9 cvs and found something that looks strange.
Should you not be using "wxSAVE|wxOVERWRITE_PROMPT" instead of "wxOPEN|wxOVERWRITE_PROMPT"?
Tim S
wxSmith\wxwidgets\wxwidgetsguiappadoptingdlg.cpp:245
void wxWidgetsGUIAppAdoptingDlg::OnCreateBtnClick(wxCommandEvent& event)
{
wxString FileName = ::wxFileSelector(
_("Please select cpp file where application class should be created"),
m_GUI->GetProjectPath(),
_T("myapp.cpp"),
_T("cpp"),
_T("C++ source files|*.cpp|All files|*"),
wxOPEN|wxOVERWRITE_PROMPT);