Recent Posts

Pages: 1 ... 4 5 6 7 8 [9] 10
81
Embedded development / Re: Including IAR-specific Library Function Definitions
« Last post by Elliott99 on December 07, 2024, 04:40:18 pm »
Thanks for the reply, and apologies for the slow response.

Attached is the rebuild log. As I said before, directly including the write.c file as one of the compiler targets fixes this, but directly including a very long absolute path to the IAR library source files seems like a poor solution.
82
Contributions to C::B / Re: Update wxWidgets project wizard
« Last post by PB on December 07, 2024, 03:06:59 pm »
Applied changes for wxWidgets >= 3.3 in 13595, thank you.

Dropping support for wx3.0 and wx3.1 is desirable but premature. I have saved your changes for a future commit.

OK.
83
Contributions to C::B / Re: Update wxWidgets project wizard
« Last post by Miguel Gimenez on December 07, 2024, 12:06:38 pm »
Applied changes for wxWidgets >= 3.3 in 13595, thank you.

Dropping support for wx3.0 and wx3.1 is desirable but premature. I have saved your changes for a future commit.
84
Contributions to C::B / Re: Update wxWidgets project wizard
« Last post by PB on December 06, 2024, 07:09:33 pm »
As for Windows:
TBH, I think people starting new wxWidgets project in year 2025 or later, who target OSes from the previous millennium, must deal with it. Whether you like it or not, starting a new project using a severally outdated wxWidgets version is a very bad idea.

Of course, one is still allowed to use whichever wxWidgets in a C::B project, one cannot just use a wizard to create one. I honestly don't think it is unreasonable and I am not exactly a youngster who likes to throw away everything slightly old.

And as for Linux, by the time new C::B version is out in the wild, it will be about 3 years since wxWidgets 3.2 release. If 3.2 is still not supported, then there must be something wrong. Anyway, the "why start a project using outdated and unsupported library version" argument still stands. Moreover, AFAIK, the trend has been to move away from linking the system libraries and pack their own with a project instead.

Either way, I am not going to argue (any further), I let the devs decide if they are interested and what they want to take.
85
Contributions to C::B / Re: Update wxWidgets project wizard
« Last post by Miguel Gimenez on December 06, 2024, 06:50:57 pm »
Wx3.0 is still supported on Linux, 3.2 is not included in most distributions. The changes for MSW look OK.

Old projects are not affected, this is only the wizard for new projects.
86
Contributions to C::B / Re: Update wxWidgets project wizard
« Last post by MichaelAgarkov on December 06, 2024, 06:47:40 pm »
Also if we remove support for old wxWidgets version will people be forced to update old projects that use them? What if they're targeting Win95 (supports only wxWidgets 3.0.x and older)?
87
Contributions to C::B / Re: Update wxWidgets project wizard
« Last post by MichaelAgarkov on December 06, 2024, 06:44:57 pm »
I actually use wxWidgets 3.0.5.
88
Contributions to C::B / Update wxWidgets project wizard
« Last post by PB on December 06, 2024, 06:38:38 pm »
Proposed changes for updating wxWidgets project wizard:
* Drop support for outdated wxWidgets 3.0 and 3.1. These versions are outdated and unsupported so it makes no sense to use them in a new project. Removing them allowed to simplify the wizard code.
* Do not allow using non-Unicode configuration for wxWidgets 3.3 and newer, where Unicode is the only text encoding supported.
* On Windows, link to Winsock2 unconditionally. wxWidgets older than 3.2 used older Winsock version so we needed to provide a choice.
* On Windows, link to gdiplus and msimg32 for wxWidgets 3.3 and newer, as required there.  wxWidgets 3.2 and older load functions from these libraries at run-time from DLLs.
* Do not link to wxAdvanced, the library does not exist in wxWidgets 3.2 and newer.

Unfortunately, I do not know how to create an SVN patch, but the changes can be previewed here: https://github.com/arnholm/codeblocks_sfmirror/commit/707654a6754fee7ef9147a639196eaa6284ccdac
89
Help / Re: Terminal to launch consol programs is grayed and not working
« Last post by stahta01 on December 05, 2024, 07:16:10 am »
The OP might want to look at the ToolPlus CB Plugin.

Tim S.
90
Help / Re: Terminal to launch consol programs is grayed and not working
« Last post by Pecan on December 04, 2024, 06:39:13 am »
Thank you for your response. I would like to keep the console windows open all the time when I am working on a project.

Could you please let me know how can it be done.

Regards,

Hamid

I'm confused by this request. A console is either a stand-alone process that belongs to no project, or it is a console attached to a running project that takes input for the running project and accepts output from the running project.

How do you expect a console to be attached to a non-running project that you are working on?

If all you want is a console that is running on it's own behalf, in Windows, hit the windows key+r and type "cmd".

If you want a console attached to a process to accept input and produce output to the a console, write a program that reads (see reading from stdin) from a console and write output to the console (see writing to stdout).

Google "c++ stdin and stdout and stderr"

In C++, stdin, stdout, and stderr are standard input, output, and error streams, respectively. They allow you to interact with the console.
Here's a breakdown:

    stdin:
    Represents the standard input stream, typically connected to the keyboard. You can use it to read input from the user.
    stdout:
    Represents the standard output stream, typically connected to the console window. You can use it to write output to the console.
    stderr:
    Represents the standard error stream, typically connected to the console window. You can use it to write error messages to the console.

How to use them:

    cin: The cin object is used to read input from stdin.
    cout: The cout object is used to write output to stdout.
    cerr: The cerr object is used to write error messages to stderr.

Example:
C++

#include <iostream>

int main() {
    int number;

    // Read input from stdin
    std::cout << "Enter a number: ";
    std::cin >> number;

    // Write output to stdout
    std::cout << "You entered: " << number << std::endl;

    // Write error message to stderr
    std::cerr << "This is an error message!" << std::endl;

    return 0;
}

Important points:

    You need to include the <iostream> header to use these streams.
    cin, cout, and cerr are objects of classes istream, ostream, and ostream, respectively.
    You can use the >> operator with cin to read different data types.
    You can use the << operator with cout and cerr to write different data types.
    You can redirect these streams using the <, >, and 2> operators in the command line.
 
Pages: 1 ... 4 5 6 7 8 [9] 10