Author Topic: Release 13.12, RC1-RC2 has arrived  (Read 57720 times)

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Release 13.12, RC1-RC2 has arrived
« Reply #45 on: December 24, 2013, 06:47:50 am »
My guess:
I'm not sure under Windows, if a key press is an accelerated key set in the mainframe, then the key press event was translated to some menu item click event.

Ok, that sounds the same as under Linux. But IMO, this behavior stinks because it means you can't use those accelerators for anything but the active editor in C::B.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5247
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Release 13.12, RC1-RC2 has arrived
« Reply #46 on: December 24, 2013, 08:17:16 am »
My guess:
I'm not sure under Windows, if a key press is an accelerated key set in the mainframe, then the key press event was translated to some menu item click event.

Ok, that sounds the same as under Linux. But IMO, this behavior stinks because it means you can't use those accelerators for anything but the active editor in C::B.
Yes, see: Re: wxAcceleratorTable - what I am doing wrong? EDIT: also http://wiki.wxwidgets.org/Catching_key_events_globally#Accelerator_table

We can:
disable the "global" accelerated key table
Or
enable the accelerated key table (and its menu item) only when editor is active
Or
Change the way we did in:
Code: [Select]
void MainFrame::OnEditCut(cb_unused wxCommandEvent& event)
{
    EditorBase* ed = Manager::Get()->GetEditorManager()->GetActiveEditor();
    if (ed)
        ed->Cut();
}

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5247
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Release 13.12, RC1-RC2 has arrived
« Reply #47 on: December 24, 2013, 03:51:23 pm »
Unfortunately, it looks like the duplicating enum problem has reappeared at some point.  Each time I refresh the CC listing, all enums, except the last one, are duplicated.
(Sorry, I am quite busy right now, and will be unable to look into it for some time.)

(Code::Blocks rev. 9487)

I can reproduce the bug by a very simple code:
A project only have one cpp file. the cpp file contains below contents.
Code: [Select]
class Y
{
    enum ABC
    {
        ebABC1,
        ebABC2,
        ebABC3,
        ebABC4,
        ebABC5,
        ebABC6
    };
};

Now, delete "C" in "ebABC3", then enter "C" again, see the screen shot:


Look, only the enumerator before the caret get duplicated.

Reason: I guess the duplicated enumerator are produced by CC try to parse a local block of the code, in this case, from the class definition start to the caret, which is:
Code: [Select]
class Y
{
    enum ABC
    {
        ebABC1,
        ebABC2,
        ebABC
So, you see, the "ebABC1" and "ebABC2" were found as some kind of enumerators which are marked as temporary. (just like the function local variables), I don't know how to fix this bug, maybe, we can still simply remove the tokens which has the same name and same Tokenkind?

I'm not sure why in your case, you have many duplications, not twice, but several times.



If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5247
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Release 13.12, RC1-RC2 has arrived
« Reply #48 on: December 25, 2013, 04:14:19 am »
My guess:
I'm not sure under Windows, if a key press is an accelerated key set in the mainframe, then the key press event was translated to some menu item click event.

Ok, that sounds the same as under Linux. But IMO, this behavior stinks because it means you can't use those accelerators for anything but the active editor in C::B.
Some information: #11320 (Accelerators take precedence over wxTextCtrl shortcuts) – wxWidgets, it looks like OBF has already reported this bug?
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Release 13.12, RC1-RC2 has arrived
« Reply #49 on: December 26, 2013, 05:54:12 am »
Some information: #11320 (Accelerators take precedence over wxTextCtrl shortcuts) – wxWidgets, it looks like OBF has already reported this bug?

So forget about my patch for release given where we are at now. But I still want to apply either my patch or something better in trunk. Clearly the wxWidgets crew aren't going to fix this without a patch that works for Mac/Linux/Windows, which could be a very long time in coming, so I think we need to workaround their bug. The question is whether there is a better approach than just removing the accelerators? (Maybe some people like that Ctrl-C/V/X/A always apply to the active editor? But they can always use the keybinder to get that behavior back) Some time back, I had played around the idea suggested in the wxWidgets trac ticket of finding the focused widget and vetoing the accelerator if it's a text-like control that has the focus, but I never did figure out how to do that correctly.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5247
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Release 13.12, RC1-RC2 has arrived
« Reply #50 on: December 26, 2013, 06:36:45 am »
Some time back, I had played around the idea suggested in the wxWidgets trac ticket of finding the focused widget and vetoing the accelerator if it's a text-like control that has the focus, but I never did figure out how to do that correctly.
I'm not quite understand what wx dev said in that trac, so if there is a workaround(patch on the function: void MainFrame::OnEditCut(cb_unused wxCommandEvent& event)???), I would like to try it on Windows.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Barrie

  • Guest
Re: Release 13.12, RC1-RC2 has arrived
« Reply #51 on: February 28, 2014, 07:15:34 pm »
I use Windows 8.1 with Code Blocks 13.12

When building a Console Project that contains 1 or more Classes in separate files the linker gives "undefined reference to [email protected]" error. Once the Project is saved, closed and then reopened the error no longer appears and the Project builds and runs normaly.

I was assured in another forum that this is probably a bug.

Please forgive me if this is not the place to comment this problem, I did read the rules and search all the fórums and this seemed to be the logical place to post it. Thanks

Barrie


Offline Squall

  • Single posting newcomer
  • *
  • Posts: 2
Re: Release 13.12, RC1-RC2 has arrived
« Reply #53 on: January 22, 2016, 01:19:36 pm »
I/ve not tried RC2 yet, but:

wxSmith, with a custom control the "Syle" property is not saved to the .wxs file.

I put a 0 in the field, but it is not saved, which gives build errors each time I re-open the project.

The following is missing <style>0</style> in my case

<object class="Custom" name="ID_CUSTOM1" subclass="wxGraph" variable="graph1" member="yes">
                           <creating_code>$(THIS) = new $(CLASS)($(PARENT),$(ID),$(POS),$(SIZE),$(STYLE),$(NAME));</creating_code>
                           <include_file>wxGraph.h</include_file>
                           <local_include>1</local_include>
                           <minsize>640,480</minsize>
</object>

which generates incorrect code, with a missing argument:

graph1 = new wxGraph(this,ID_CUSTOM1,wxDefaultPosition,wxDefaultSize,,_T("ID_CUSTOM1"));

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12124
    • Travis build status
Re: Release 13.12, RC1-RC2 has arrived
« Reply #54 on: January 22, 2016, 08:05:05 pm »
So what version have you used?
Hopefully it wasn't 13.12rcX, because there is 13.12 final release and also there is the 15.12rc1!  :o
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Squall

  • Single posting newcomer
  • *
  • Posts: 2
Re: Release 13.12, RC1-RC2 has arrived
« Reply #55 on: January 22, 2016, 11:23:45 pm »
So what version have you used?
Hopefully it wasn't 13.12rcX, because there is 13.12 final release and also there is the 15.12rc1!  :o

Sorry, 15.12RC1. I'll try latest shortly