C / C++ / MFC

Well, I am getting few "try it this way". I believe there are many ways to "skin a cat" , but these well meaning alternative suggestion are distraction from the task at hand. Actually I have to "back-paddle " in my "foreach"' approach. Before I can iterate I have to have a list and it better be of compatible type... That also applies if I use any of the Qt ways to iterate... Cheers

Please do not do this. I posted a response which explained the situation. Now anyone who reads my response will have no idea what your question was even about.

Much the same issue as Re: How to track "nested objects "? - C / C++ / MFC Discussion Boards[^]. If you cannot be bothered to format your code as requested many times, do not be surprised if people here cannot be bothered to help you.

Probably not since we have no idea what the problem may be. The debugger is there to help you to find the point at or near where your code has a problem. So make use of it, and when you have some proper details then post a proper question.

:) Thank you! "In testa che avete, Signor di Ceprano?" -- Rigoletto

This is what I understand from the above: 1. MainWindow_Bluetooth is a class that contains various properties including m_settings. When instantiated m_settings is set to point to a new SettingsDialog. 2. SD is a pointer to a new SettingsDialog. No idea where it is created or why, since this appears to be a duplicate of m_settings. 3. In the closeEvent of SettingsDialog you create some text and pass it to m_TAB_Connect, presumably to be displayed somewhere. It is not possible to say whether this is called by SD or m_settings since other parts of the code are not present.

Let's try and look at this set of parameters line by line 1. Why are you calling QDialog here? That line of code creates a new QDialog object, but you do not save any pointer to it, so what is the reason for that? QDialog(parent), 2. I assume that m_ui is declared as a pointer to a Ui::SettingsDialog which you will refer to somewhere later. m\_ui(new Ui::SettingsDialog), 3. As with point 2 you create a new object whose pointer you store in m_status. m\_status(new QLabel), 4. Possibly the same as 2 and 3 but I have no idea what m_TAB_Connect is. Is it a pointer, or a method? m\_TAB\_Connect(new A\_BT\_TAB\_DIALOG), 5. Same as comment 4. m\_intValidator(new QIntValidator(0, 4000000, this)) So without further details of the class it is impossible to say whether this is correct or not. Constructors really should do the minimal initialisation necessary to create the object, that is just setting properties that do not require callouts to other classes. Any calls to other constructors, methods, API functions etc. is generally best left to an initialisation method.

Sorry , I got sidetracked fixing the issue. I have been told , not just advised, NOT to post Qt questions. Since I am not welcomed to do so I , on my own, do not want to discuss Qt here. I think that is fair. Cheers

It's a question of taste: put the underscore at the other end (ostream_), or come up with a different name (ostrm). As in any question of taste, there isn't any right answer; my personal preference goes for trailing underscore. The rule about leading underscore is not my invention. See C++ Language standard section 17.6.4.3.2 - Global names (page 429). Mircea

May I please inquire are you stating the compiler you are utilizing provides no means to specify a list of directories to search for #include's. That is difficult to believe. May I please inquire compiler purveyor.

Whenever I have such questions and I have them often I experiment w/ brief simple code and observe the behavior.

SOLVED DEFINES = " "

Look at the error message (again): mainwindow.cpp:(.text+0x270): undefined reference to `ORIGINAL_TERMINAL_MainWindow::ORIGINAL_TERMINAL_MainWindow(QWidget*) In your mainwindow.cpp source you are calling the constructor of the ORIGINAL_TERMINAL_MainWindow class. But the linker did not find a definition of that constructor anywhere in the modules and libraries that are being used to build your application. So you need to find out exactly where it is defined and why the linker cannot find it.

Sorry, I mixed up C and make. THANKS

I am still using this 2024. Your example is useful and helped me through the jungle. i is an integer not a string. varindex.lval = i; Than things are working, already. Maybe someone else can use.

If symbol is declared in the global namespace, it's still visible from other namespaces. If it's also declared in a named namespace, that's the declaration that would be picked up within that namespace unless qualified as ::symbol. You're right that a forward declaration isn't required if you define the class--in the same file. There are times when an interface (.h) forward-declares a class that it uses in name only, and which is private (that is, implemented in its .cpp). This is done when using the PIMPL idiom[^]. Robust Services Core | Software Techniques for Lemmings | Articles The fox knows many things, but the hedgehog knows one big thing.

Maybe its a contest. Guess the point and win the prize. I do note that there are two possible inputs. So if '1' was put in for the first one, then I expect it works. If put in for the second then I suspect '2', ..., '9' would also fail.

Do your own schoolwork. The difficult we do right away... ...the impossible takes slightly longer.

You are welcome. And NASM is a good introduction to Assembler, and machine code.