Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

wxSmith - tutorial

<< < (5/10) > >>

The Falcon:
To BYO:

    I posted a couple of days ago (my appreciation for the recent wxSmith work) and now I'm back, as promised, with further feedback, observations and possible minor glitches. I've got to say that on the whole my play around with wxSmith has been a really enjoyable experience and I have yet to encounter anything which seems a major bug. Please advise, for future reference, whether posting this type of stuff here is appropriate or is formal bug reporting the more desired option?  OK, well I have not by any means been extensive in my testing/playing but I've done a little bit which has led to the obsrvations outlined below. I hope these help in your quest to get wxSmith to a satisfactory stable state. For reference I am using C::B downloaded from CVS about three days ago, with the bundled RC2 MinGW and wxWidgets-2.6.2 on a Win2000 platform. Well let's get to it:

1. When using the preview facility after only defining a panel and a sizer the minimal preview dialog is displayed. The normal 'x' close button doesn't seem to respond. You can still close if you right click on the header and select 'close', so it's a minor annoyance but I suppose the 'x' close button should really work.

2. The hotkey/accelerator key assignments are not displayed in the preview. i.e. No underlines etc. This seems a bit weird as you can happily play with a combo box and buttons etc. in preview but the first time I saw the buttons I thought I'd forgotten to do the old '&' insertion. I hadn't, it just wasn't reflected in the preview.

3. Subsequent to the already identified 'Black Screen Issue' I noticed that this also occurs when you use the border size spin control in the size options panel. It doesn't do it for ever click, just after a few, and it isn't persistent as it usually returns to normal on clicking up or down to the next value.

4. Another one that may be related to the above (but it's really minor) and may help to lead to the source of the problem is that the size anchor tabs (the little black size tabs around the selected control/widget) flicker madly when you have something selected in wxSmith and use the C::B main menu. It doesn't happen for all menus and I struggled to get a consistent respnse but it does happen if you activate a menu then sweep across the menu titles.

5. When using the properties/events pane to define an event handler you are presented with a small dialog to define the event name. If you choose cancel here, instead of defining a name and pressing OK, the event pane does not re-paint correctly. It will re-paint if you go to the properties tab and then return, but I guess that's not really what you intend.

6. I have a more interesting issue with hidden controls/widgets and their usage with wxSmith but I'm not sure if it's a wxSmith issue. It may be related to wxWidgets, and how they work with sizers (I am reasonably new to both wxWidgets and C::B but ancient as far as C++ and RAD GUI interfaces go) so maybe I just need to be pointed at some documentation on how to manipulate hidden widgets in relation to sizers etc. I notice with interest that when you use the properties window to set the HIDDEN property in wxSmith the selected widget is moved to the top of the display and the container/sizer is resized. Also, when hidden, the widget still appears in the preview facility as if it was still visible. Hmmm. this might be a tad confusing to some. Anyway I tried shifting the widget->hide() code around in the source (and re-compile) and did get it to appear in locations other than at the top of the dialog but as yet I have'nt been able to get it to work properly. Most likely it's a product of my relative inexperience with wxWidgets but any light you can shed on this would be helpful, or is it something I should forward to the wxWidgets forum? Have you experienced any difficulties with this issue in the wxSmith implementation?

Anyway that's it for now, hope some of this helps, and keep up the great work,,,,

Kind Regards,
    The Falcon.  :D

PS: Love the widget multi-select property setting. Sort of didn't ecpect it at this stage but there it is, well done.

byo:

--- Quote from: Takeshi Miya on November 17, 2005, 12:31:08 am ---and the panels are going to be managed by wxDockIt?

--- End quote ---

I don't plan it currently because there was discussion about switching to wxIFM. And I'll wait till there's a final dedcission about that :)

byo:

--- Quote from: The Falcon on November 17, 2005, 04:30:59 am ---Please advise, for future reference, whether posting this type of stuff here is appropriate or is formal bug reporting the more desired option?

--- End quote ---

I advise using SF bug reporting system - Ii will be easy to manage them and hard to forget ;)


--- Quote ---1. When using the preview facility after only defining a panel and a sizer the minimal preview dialog is displayed. The normal 'x' close button doesn't seem to respond. You can still close if you right click on the header and select 'close', so it's a minor annoyance but I suppose the 'x' close button should really work.

--- End quote ---

This seems to be wxWidgets bug or even more - Windows one. I'll se what can be done but now it will be delayed.


--- Quote ---2. The hotkey/accelerator key assignments are not displayed in the preview. i.e. No underlines etc. This seems a bit weird as you can happily play with a combo box and buttons etc. in preview but the first time I saw the buttons I thought I'd forgotten to do the old '&' insertion. I hadn't, it just wasn't reflected in the preview.

--- End quote ---

I'll have to take a closer look at this. Sometimes I see underline and sometimes i don't :? Really weird ;)


--- Quote ---3. Subsequent to the already identified 'Black Screen Issue' I noticed that this also occurs when you use the border size spin control in the size options panel. It doesn't do it for ever click, just after a few, and it isn't persistent as it usually returns to normal on clicking up or down to the next value.

--- End quote ---

This bug seems to be a bigger one :( I have some idea but it will require some time


--- Quote ---4. Another one that may be related to the above (but it's really minor) and may help to lead to the source of the problem is that the size anchor tabs (the little black size tabs around the selected control/widget) flicker madly when you have something selected in wxSmith and use the C::B main menu. It doesn't happen for all menus and I struggled to get a consistent respnse but it does happen if you activate a menu then sweep across the menu titles.

--- End quote ---

Somehow connected with the previous one. I guess it will have biggest proprity assigned ;)


--- Quote ---5. When using the properties/events pane to define an event handler you are presented with a small dialog to define the event name. If you choose cancel here, instead of defining a name and pressing OK, the event pane does not re-paint correctly. It will re-paint if you go to the properties tab and then return, but I guess that's not really what you intend.

--- End quote ---

That should be easy. I know that there are more situations like this. If You notice any, please notice me :)


--- Quote ---6. I have a more interesting issue with hidden controls/widgets and their usage with wxSmith but I'm not sure if it's a wxSmith issue. It may be related to wxWidgets, and how they work with sizers (I am reasonably new to both wxWidgets and C::B but ancient as far as C++ and RAD GUI interfaces go) so maybe I just need to be pointed at some documentation on how to manipulate hidden widgets in relation to sizers etc. I notice with interest that when you use the properties window to set the HIDDEN property in wxSmith the selected widget is moved to the top of the display and the container/sizer is resized. Also, when hidden, the widget still appears in the preview facility as if it was still visible. Hmmm. this might be a tad confusing to some. Anyway I tried shifting the widget->hide() code around in the source (and re-compile) and did get it to appear in locations other than at the top of the dialog but as yet I have'nt been able to get it to work properly. Most likely it's a product of my relative inexperience with wxWidgets but any light you can shed on this would be helpful, or is it something I should forward to the wxWidgets forum? Have you experienced any difficulties with this issue in the wxSmith implementation?

--- End quote ---

Nice catch. But this confusing behaviour seems to be wxWidgets one. Other thing is that wxSmith does not do anything to make it less confusing ;). I'v noticed that sizers check what widgets are hidden inside it and when whole row / column of widgets is hidden, it won't be displayed at all and no place will be reserved for them...
I see only one difference in my case - hidden widgets are not moved to the top of the window but they're placed somewhere betwen it's neighbours. Can You post some screenshoot ?


--- Quote ---Anyway that's it for now, hope some of this helps, and keep up the great work,,,,

--- End quote ---

Thx for Your work :)


--- Quote ---PS: Love the widget multi-select property setting. Sort of didn't ecpect it at this stage but there it is, well done.

--- End quote ---

Hmm, can You check again ? You have surprised me too  :D But I'll think about it.

The Falcon:
Thanks for the response BYO,

    first off regarding my previous PS: about the multi-select property setting, woops  :? I think I got carried away. I re-checked as advised and I was mistaken. This is a very useful feature though, i.e. being able to select multiple (alike) widgets and setting properties (such as font, or foreground colour) that are common to each widget. I can understand though that it would not be a priority in the short term. Perhaps one for the future enhancements basket.
    OK now to the requested info on the hidden widgets issue. This little test was simply an extension of your excellent little tutorial with a few small features changed to allow me to become more familiar with things. I'll outline what I did so you can get a better idea of the real issue.

1. I created a dialog and inserted a box sizer with vertical orientation.
2. I inserted a wxStaticText label followed by a wxComboBox filled with ten items.
3. I then placed another wxStaticText label below this.
4. To be a little more adventurous I placed a wxStaticBox below at the bottom with horizontal orientation, in this I placed two buttons with a spacer in between, just for kicks.

This is how it looks:



as you can see the object is to select from the wxComboBox and see the selection reflected in the wxStaticText widget. This works nicely until you get a bit fancier and try hiding the wxStaticText widget and displaying it only after a selection has been made from the combo. If you hide it directly from wxSmith->Properties-HIDDEN the widget disappears and some outlined tabs are visible in the design area, at the top of the dialog. It looks like this in wxSmith:



Here's what it looks like when compiled and displayed after first combo selection.



If I move the hide instruction (inserted by wxSmith after property setting) down to the bottom of TestDialog::TestDialog which is my constructor in testdialog.cpp then it comples like this:




The code seems to perform all the right functionality but it's just the weird positioning that causes the problem. I think you are most probably on the mark with thinking it may be a wxWidgets problem, but I hope this all makes it a bit clearer for you. I might poke around the wxWidgets site and see what I can find. If I resolve it I'll get back to you.

Incidentaly, do you want me to post this and perhaps the other points I mentioned last time to the SF bug system? Either way I'll try to do it that way from now on. Thanks for your time.

Regards,
    The Falcon.  :D

byo:
Ok, now I see what's here.

Because sizers position this hidden text, it's place is not set when it's hidden flag is set. I'll have to think on really easy way of representing such widgets in wxSmith cause current representation can be really confusing :)

And the second problem - on runtime You have to call Layout() after hiding / unhiding text.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version