Release 13.12, RC1-RC2 has arrived

[dmoore]

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.

[ollydbg]

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 Expand


void MainFrame::OnEditCut(cb_unused wxCommandEvent& event)
{
   EditorBase* ed = Manager::Get()->GetEditorManager()->GetActiveEditor();
   if (ed)
       ed->Cut();
}


[ollydbg]

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 Expand


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 Expand


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.

[ollydbg]

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?

[dmoore]

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.

[ollydbg]

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.

[Barrie]

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 WinMain@16" 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

[BlueHazzard]

http://wiki.codeblocks.org/index.php?title=FAQ-Compiling_%28general%29#Q:_How_do_I_report_a_compilation_problem_on_the_forums.3F

[Squall]

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"));

[oBFusCATed]

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! 

[Squall]

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! 

Sorry, 15.12RC1. I'll try latest shortly