Recent Posts

Pages: 1 [2] 3 4 5 6 7 ... 10
11
Plugins development / Re: Code completion using LSP and clangd
« Last post by Pecan on January 23, 2022, 09:59:29 pm »
CB Clangd Client / Code / Commit [r32]

Please note that in this revision.
I'm using the Windows clangd_client_wx31_64.cbp
The generated dll file name is:  Clangd_Client.dll
And the zip file name is: clangd_client.zip

Do you think the name should be the same? I mean to keep the case consistent.

I do, but others did not. Wasn't worth quibbling about to me.

Thanks for the wxUniChar fix.
12
Development / Bug in AddMultipleFilesToProject
« Last post by BlueHazzard on January 23, 2022, 09:55:14 pm »
Code
int ProjectManager::AddMultipleFilesToProject(const wxArrayString& filelist, cbProject* project, int target)
{
    if (!project)
        project = GetActiveProject();

    wxArrayInt targets;
    targets.Add(target);
    if (AddMultipleFilesToProject(filelist, project, targets) == 1)
        return targets[0];
    return -1;
}

The documentation says, that in this function, if the parameter target == -1 then the user gets asked for the targets to add...
Now, AddMultipleFilesToProject calls DoAddFiles
Code
nt ProjectManager::DoAddFileToProject(const wxString& filename, cbProject* project, wxArrayInt& targets)
{
    if (!project)
        return 0;

    if (!SetupTargets(targets, project, m_ui))
        return 0;

And do add files calls setupTargets

Setup targets checks if the targets array is empty and if so, asks the user for the targets...
In our case the array is not empty, but filled with -1 so the documentation is wrong
Code
bool SetupTargets(wxArrayInt &targets, cbProject *project, cbProjectManagerUI *ui)
{
    cbAssert(project);
    cbAssert(ui);

    // do we have to ask for target?
    if (targets.GetCount() == 0)
    {

Or am i missing something?
13
Plugins development / Re: Code completion using LSP and clangd
« Last post by ollydbg on January 23, 2022, 03:58:56 pm »
I see an alert from this code snippet, and here is the fix:

Code
 clangd_client/src/LSPclient/src/client.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clangd_client/src/LSPclient/src/client.cpp b/clangd_client/src/LSPclient/src/client.cpp
index 459b809..e03730d 100644
--- a/clangd_client/src/LSPclient/src/client.cpp
+++ b/clangd_client/src/LSPclient/src/client.cpp
@@ -1073,7 +1073,7 @@ bool ProcessLanguageClient::DoValidateUTF8data(std::string& data)
             std::string invStr(&data[invloc], 1);
             //unsigned int invInt = (unsigned int)data[invloc];
             unsigned char invChar(invStr[0]);
-            wxUniChar uniChar(invChar);
+            wxUniChar uniChar((unsigned int)invChar);
 
             // clangd response:
             // {"id":"textDocument/completion","jsonrpc":"2.0","result":{


When debugging, I see that the "invChar" is 161(dec), and it cause the alert from wx.
So, we have to first convert to "unsigned int".

See the document from: wxWidgets: wxUniChar Class Reference


Quote
wxUniChar::wxUniChar    (    unsigned char     c   )    

Create a character from the 8-bit character value c using the current locale encoding.
14
Nightly builds / Re: The 22 January 2022 build (12672) is out.
« Last post by eckard_klotz on January 23, 2022, 01:46:41 pm »
Hello Miguel Gimenez.

Quote
@eckard_klotz: Works here with the last version, have you tried after restoring the configuration?.
Quote
Please restore your compiler toolchain configuration (with the global variables) and check if it works.

The question is what do you understand as "restoring the configuration" ?

When I read that it is working for you I tried it again and yes you are right it was working as wanted:
  • The revision 12672 has not started the "Compilers Auto Detection" dialogue
  • The compiler settings contain all global variables as configured manually.

The reconstruction was done based on the conf-file left by the  revision 12672 yesterday.
  • I have just replaced the literal information by the global variables.

Now I wondered what I have done wrongly yesterday
  • I repeated step by step what I have done but with a different conf-file I have not used since August 2021.
  • Furthermore please notice, that I have used until yesterday the revision 12516 from August the 15th 2021.
  • Attached you will find a ZIP-file with screen shots and conf-files I mention in the description below.

  • I started Code::Blocks revision 12516 with the configuration "MinGW_9_2_0_64bit_TDM_Original.conf"
    • No "Compilers Auto Detection" dialogue occurred.
    • The configuration of the "Compiler Toolchain Executables" contained global variables ("CB_12516_compiler_toolchain_executables.png").
    • After closing Code::Blocks the file "MinGW_9_2_0_64bit_TDM_ref12516.conf" was stored.
  • Now I started Code::Blocks revision 12672 with the conf-file stored by the revision 12516 "MinGW_9_2_0_64bit_TDM_ref12516.conf".
    • The "Compilers Auto Detection" dialogue occurred.
    • The configuration of the "Compiler Toolchain Executables" contained not all global variables as desired but a lot of literal configurations ("CB_12762_compiler_toolchain_executables.png").
    • After closing Code::Blocks the file "MinGW_9_2_0_64bit_TDM_ref12762.conf" was stored.
    • Please notice, that this file is 3 kb larger than the original one.
  • Now I have corrected the content of the new conf-file by reconstructing the gcc configuration as present in the original conf-file.
    • I left anything else as stored by the revision 12762.
  • At the end I started Code::Blocks revision 12762 with the corrected configuration "MinGW_9_2_0_64bit_TDM_ref12672_Corrected.conf."
    • No "Compilers Auto Detection" dialogue occurred.
    • The configuration of the "Compiler Toolchain Executables" contained global variables as desired.

OK, after a manual correction of the configurations overwritten by Code::Blocks it is keeping the global variables again.
  • For a single user this may be a workaround.
  • But the user has to check every single configuration he has done in the past to ensure not to oversee a hidden modification.
  • Furthermore, this has to be done with every revision change since the user could not know when the conf-file format was changed.

I know where the conf-files are located on my computer:
  • C:\Users\[USER_NAME]\AppData\Roaming\CodeBlocks
  • Thus I have the chance to store the conf-files before changing the Code::Blocks revision to compare it later with the conf-files stored by the new revision
  • But how many Code::Blocks users are realy able to do the same


Best regards,
                    Eckard Klotz.
15
Plugins development / Re: Code completion using LSP and clangd
« Last post by ollydbg on January 23, 2022, 12:47:55 pm »
CB Clangd Client / Code / Commit [r32]

Please note that in this revision.
I'm using the Windows clangd_client_wx31_64.cbp
The generated dll file name is:  Clangd_Client.dll
And the zip file name is: clangd_client.zip

Do you think the name should be the same? I mean to keep the case consistent.
16
Nightly builds / Re: The 22 January 2022 build (12672) is out.
« Last post by Miguel Gimenez on January 23, 2022, 12:43:56 pm »
Please restore your compiler toolchain configuration (with the global variables) and check if it works.
17
Nightly builds / Re: The 22 January 2022 build (12672) is out.
« Last post by eckard_klotz on January 23, 2022, 12:02:01 pm »
Hello Miguel Gimenez.

Here you are:

Quote
C:\Users\Eckard>PATH
PATH=C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\ProgramData\Oracle\Java\javapath;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Intel\OpenCL SDK\2.0\bin\x86;C:\Program Files (x86)\Intel\OpenCL SDK\2.0\bin\x64;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;\;C:\Program Files (x86)\Sony\VAIO Startup Setting Tool;C:\Program Files (x86)\T-Online\T-Online_Software_6\Basis-Software\Basis2\;C:\Tool\DEVELO~1\Graphiz\GRAPHV~1\bin\Graphviz\bin;C:\Tool\Development\Doxygen\DoxyGen_1_8_7\bin\bin;C:\Tool\Development\MscGen\V_0_2_0\bin\Mscgen;C:\Tool\Development\MinGW\MinGW_4_8_1_3_DW2\bin;C:\Tool\Development\MinGW\MinGW_4_9_2\bin;C:\Tool\Development\Doxygen\DoxyGen_1_8_8\bin\bin;C:\Tool\Office\LaTeX\LyX\Release\Perl\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Tool\Development\Doxygen\DoxyGen_1_8_11\release\doxygen\bin;C:\Tool\Development\Doxygen\DoxyGen_1_8_12\release\bin;C:\Tool\Development\Doxygen\DoxyGen_1_8_13\release\doxygen\bin;C:\Tool\Development\PuTTy\bin\;C:\WINDOWS\System32\OpenSSH\;C:\Tool\Development\SVN\Tortoise\Install\bin;C:\Tool\Development\GIT\Installed\cmd;C:\Tool\Development\MinGW\MinGW_9_2_0_TDM\bin_64\bin;C;C:\Tool\Office\LaTeX\CTAN\texlive\2020\bin\win32;C:\Users\Eckard\AppData\Local\Microsoft\WindowsApps;

Best regards,
                     Eckard Klotz.
18
Nightly builds / Re: The 22 January 2022 build (12672) is out.
« Last post by Miguel Gimenez on January 23, 2022, 11:57:05 am »
@AndrewCot: Fixed in r12674

@eckard_klotz: Works here with the last version, have you tried after restoring the configuration?. Please post your path.
19
Nightly builds / A
« Last post by Xaviou on January 23, 2022, 11:07:38 am »
Hi

I finally took the time to make the DnD tests (sorry I didn't thought about these ones when I made the firsts tests).

Here are the results :

Dragging files from outside to:
1) An open editor : opens a new editor tab with this file but don't add the file to the current project : it is opened as an external file.
2) The project Tree : On the workspace entry of the tree, it does nothing. On a project entry, it add the files to the project. But it has not the exact same behavior than using "Project -> Add files". With DnD, the file is added to the project but it isn't "activated" for any build target". With menu entries, a dialog box appears to select the targets to with this file belongs.
3) To a specific project in the project tree : Tested with a multi-projects tree. The dragged files are added to the active project only, even if I drop them on another project.
4) To a virtual folder in a project tree : The files are correctly added to the selected virtual folder, with the same restrictions than for step 2

I also obtained a lot of crashs during the tests (and most of the time, I had to kill the Code::Blocks process using the activity monitor).
All these crashs appeared if I tried to make more than one DnD test with a C::B session (sometimes but rarely, I was able to make 2 following successfull tests, but never more).

I've attached 3 debug reports if it can help. (they seems to contain the same informations).

Regards
Xav'
20
Nightly builds / Re: The 22 January 2022 build (12672) is out.
« Last post by eckard_klotz on January 23, 2022, 09:02:55 am »
Hello Miguel Gimenez and AndrewCot.

I assume that you have respond to my request (but I'm not sure).

From my perspective the main issue is not the automatic tool detection. The issue is that Code::Blocks is changing the configuration of the user.

For somebody who is new in Code::Blocks and/or C/Cpp programming features like tool auto-detection are definitely very helpful, no doubt about that.
  • But if a user decides to modify the configuration this automatism must not work against the user.
  • Using global variables instead of hard-coding makes it possible to use the same global variable more than once while its definition is centralized and has to be maintained only once.

If I place in a configuration dialogue global variables (in my case the "Compiler Toolchain Executables") I actually expect that this adjustment will not be changed but kept.
  • Thus please ensure that Code::Blocks is not modifying the configuration-properties which are using global variables as value.

Is there an application parameter similar to --personality="ask" that could be used while starting Code::Blocks to suppress the auto-detection and all associated auto-configurations?
  • Consequently all auto detections may already be suppressed if Code::Blocs starts not with default.conf. after using --personality="ask".
  • In this case the user made very clear that an already prepared configuration should be used.

Please stay well and healthy,
                                         Eckard Klotz.
Pages: 1 [2] 3 4 5 6 7 ... 10