|
Thanks for that.
Yep, i just started there quite fresh as well but it seems i am, because of the tasks i was assigned to, the one that finally starts to clean up some old things. And yes, it'll be fun if something unexpected happens.
I'll keep the last bit in mind and will address this task to my superior.
Rules for the FOSW ![ ^]
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found");
|
|
|
|
|
HobbyProggy wrote: to ensure communication via Ethernet, USB and Bluetooth.
As described all of those currently exist without customization. One might also wonder if this custom stuff is secure. Specifically how is be being tested to insure that it is secure and will remain so.
HobbyProggy wrote: windows 10 (which is our current limit of support)
Windows 10 runs on 64 bit systems but it also runs on 32 bit systems.
HobbyProggy wrote: We leave aside the fact that nobody else from the team would have hardware to continue coding or even compile this old stuff.
Presumably the company at least has the source code.
And yes there are risks to the company in not insuring continuity in case there are problems.
|
|
|
|
|
jschell wrote: As described all of those currently exist without customization. One might also wonder if this custom stuff is secure. Specifically how is be being tested to insure that it is secure and will remain so.
Yep... Uhm ... exactly one of the first things i was asking when i heard that, on the plus side i was able to read the whole BLE traffic with a sniffer when i was asked to measure and verify time needed for updates over ble.
jschell wrote: Windows 10 runs on 64 bit systems but it also runs on 32 bit systems.
Yep, i should have mentioned we need both.
jschell wrote: Presumably the company at least has the source code.
And yes there are risks to the company in not insuring continuity in case there are problems.
I am also asking the question because i want to ensure that we will not be screwed if something funny happens.
All the info will be used to lay out a plan and strategy to not fall off the edge.
Rules for the FOSW ![ ^]
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found");
|
|
|
|
|
HobbyProggy wrote: that we will not be screwed if something funny happens.
You need not suggest anything 'funny'.
Heart attack. Fire. Tornado. Flood. Etc.
What happens to the company if those happen to that single person.
|
|
|
|
|
for(int i=0;i<3;i++)
{
vector<thing*> * Nodes = new vector <thing*>();
thing * Athing = new thing();
Nodes->push_back(Athing);
}
do I need to delete the vector once the work is done or this is not required?
How about the things stored inside the container, do I need to delete those too or calling clear() is enough.
for(int i=0;i<3;i++)
{
vector<thing*> * Nodes = new vector <thing*>();
thing * Athing = new thing();
Nodes->push_back(Athing);
Nodes->clear();
delete Nodes;
}
modified 9-May-24 9:22am.
|
|
|
|
|
Calin Negru wrote: do I need to delete the vector once the work is done?
for(int i=0;i<3;i++)
{
vector<thing*> * Nodes = new vector <thing*>();
thing * Athing = new thing();
Nodes->push_back(Athing);
//do stuff
Nodes->clear();
delete Nodes;
}
Yes, you do.
Since you created it (vector) with new then you need to delete the vector once the work is done
|
|
|
|
|
What happens if I don’t delete the vector, will that cause a memory leak or it’s just allocated memory that is not used and takes extra space. The program doesn’t break with an error when I do source code version No 1
I have unexpected behavior somewhere else in my program and I was wondering if this could be the cause of it.
modified 9-May-24 10:43am.
|
|
|
|
|
With a memory leak, the memory footprint of the running process increases over time. If the conditions that lead to the leak are encountered often enough, the process will eventually run out of available memory, usually causing an exception of some sort. Unless you're in a very specialized environment, the memory associated with the process gets released when it exits. That means that the overall memory on the system doesn't get incrementally consumed over time. So you really only run the risk of the one process running out of memory, not the system as a whole. I hope I've explained that clearly enough.
Some system calls (and some user written functions!) use this to their advantage. On the first call they will allocate some memory, and then reuse it on successive calls. With no cleanup routine, they just rely on the program exit to do the memory release. That's why you might get notice of memory in use at exit when running a program under a memory diagnostic tool like Valgrind. When you trace back to where the memory was allocated, it might be inside something like fopen().
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
Thanks k5054 I think I understand. What I described in the first example is a memory leak but probably is not causing problems elsewhere.
|
|
|
|
|
If by "not causing problems elsewhere" you mean it's not affecting other processes, that's mostly true. You can, of course, run into an Out Of Memory (OOM) situation, where all the RAM and swap is marked as "in use", and Bad Things start happening. Assuming you've got a 64 bit OS with lots of RAM and swap configured, (heck, even a 32 bit OS with good Virtual Memory), that's only likely to happen if you've got a lot of memory allocated.
As a rule of thumb, you should clean up memory when it's no longer needed. Think of it like craftsmanship. A piece of Faberge jewelry shows attention to detail from both the back and the front. Freeing up unused memory is part of the attention to detail, just like closing files after use, for example.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
On top of what Victor said, look into using std::unique_ptr instead of "naked" pointers. Something like this:
auto Nodes = new std::vector< < std::unique_ptr<Thing> >;
Nodes->push_back( std::make_unique<Thing>() );
delete []Nodes;
Edit:
It is a bit unusual to "new" vectors. Given they can grow dynamically, in most cases you would write something like:
std::vector<<std::unique_ptr <Thing> >nodes;
nodes.push_back (std::make_unique<Thing>( ) );
When nodes goes out of scope all Things get deleted automatically.
Mircea
modified 9-May-24 9:41am.
|
|
|
|
|
Yes, you have to explicitly delete the vectors you allocated using new.
But that's not enough.
Try running the following code
#include <iostream>
#include <vector>
using namespace std;
class thing
{
public:
thing(){cout << "thing ctor\n";}
~thing(){cout << "thing dtor\n";}
};
int main()
{
for(int i=0;i<3;i++)
{
vector<thing*> * Nodes = new vector <thing*>();
thing * Athing = new thing();
Nodes->push_back(Athing);
Nodes->clear();
delete Nodes;
}
}
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Thank you guys for your feedback. I think I understand what a memory leak is now.
|
|
|
|
|
You are welcome.
As suggested, have a look at smart pointers, they could make your coding life easier.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Hi,
I have considerable work with mfc but not quite familiar with controlling USB power through windows resources programmatically. Any codes or material available?.
|
|
|
|
|
etechX2 wrote: I am beginner
A beginner programmer should not attempt that. You would need to learn quite a bit of just programming in C++ and then programming for windows and then programming to the device interface.
|
|
|
|
|
|
yeah, you are going to be down into device drivers and what not. I'm sure Microsoft has an API somewhere, but it'll change.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
I am asking for code assistance, I am NOT asking for opinions, to implement
"foreach" to be able to write something likes
"action-> trigger this code "
I am asking for code help to rewrite this to recursively go thru the object hierarchy until "textMatch" is found
<pre>
QString textMatch = test; QList<QAction*> pTEST = parent->findChildren<QAction *>();
foreach( auto *action, pTEST)
{
text = action->objectName();
qDebug().noquote() << text;
if(text.contains(textMatch))
{
#ifdef RETILE
text = "match found parent ";
text += parent->objectName();
text += "\n action ";
text += action->objectName();
qDebug().noquote() << text;
#endif
action->trigger();
text += " foreach match ";
qDebug().noquote() << text;
return 0;
break;
}
}
The code abiove works fine "in single stage",
I need it to iterate , using foreach preferred, but not mandatory, thru the entire tree.
PLEASE NOTE
This is an "under construction code " and will be deleted AFTER solution is found.
"actionTile_subwindows" QAction
Locals
event @0x7fffffffca20 QCloseEvent
mdiParent @0x7ffff4ea5453 QMdiSubWindow
pActions <not accessible> QList<QAction*>
pL <not accessible> QList<QObject*>
pLParent <not accessible> QList<QObject*>
pLParent_Action <not accessible> QList<QAction*>
pOBJECT 0x5d0000006e QWidget*
pTEST @0x7fffffffc550 QWidget
this "SettingsDialog" SettingsDialog
[QDialog] "SettingsDialog" QDialog
[d] @0x555555d923e0 QDialogPrivate
[parent] @0x555555de3310 QMdiSubWindow
[QWidget] @0x555555de3310 QWidget
[d] @0x5555556d1000 QMdiSubWindowPrivate
[parent] @0x555555c30e80 QWidget
[QObject] @0x555555c30e80 QObject
[QPaintDevice] @0x555555c30e90 QPaintDevice
[d] @0x555555c30ec0 QWidgetPrivate
[parent] @0x555555c64250 QMdiArea
[QAbstractScrollArea] @0x555555c64250 QAbstractScrollArea
[d] @0x5555559ff1a0 QMdiAreaPrivate
[parent] "MainWindow_Bluetooth" MainWindow_Bluetooth
[QMainWindow] "MainWindow_Bluetooth" QMainWindow
[d] @0x555555c2ed00 QMainWindowPrivate
[parent] @0x555555ccf290 QMdiSubWindow
[children] <35 items> QList<QObject*>
[0] "_layout" QMainWindowLayout
[1] @0x555555c64250 QMdiArea
[2] "SettingsDialog" SettingsDialog
[3] @0x555555cdddc0 QSerialPort
[4] "actionAbout" QAction
[5] "actionAboutQt" QAction
[6] "actionConnect" QAction
[7] "actionDisconnect" QAction
[8] "actionConfigure" QAction
[9] "actionClear" QAction
[10] "actionQuit" QAction
[11] "actionVirtual_serial_port" QAction
[12] "actionBluetooth_virtual_port" QAction
[13] "actionBluetooth" QAction
[14] "actionBluetooith_virtiual_port" QAction
[15] "actionBluetooth_service_enable" QAction
[16] "actionWinsow_control" QAction
[17] "actionWindoiw_control" QAction
[18] "actionTEST_tile" QAction
[19] "actionTEST_resize" QAction
[20] "actionTile_subwindows" QAction
[21] "actionCascade_subwindows" QAction
[22] "actionMaximize_current_subwindow" QAction
[23] "actionTEST" QAction
[24] "actionSubmenu_1" QAction
[25] "actionSubmenuy_2" QAction
[26] "actionClear_all_windoiws" QAction
[27] "actionClear_all_windiws" QAction
[28] "actionSerial_test" QAction
[29] "actionSerial_test_2" QAction
[30] "actionC_code_scan" QAction
[31] "actionSelect_MDI_subwindow_MDI_window_control" QAction
[32] "menuBar" QMenuBar
[33] "mainToolBar" QToolBar
[34] "statusBar" QStatusBar
[properties] <at least 0 items>
[methods] <20 items>
[extra]
Menu_Index 0 int
command 0x0 char*
index 8 int
index_sub 0 int
list_array @0x555555bd2370 QStringList[10]
m_TAB_CommonDebug "A_BT_TAB_DIALOG" A_BT_TAB_DIALOG
m_TAB_Connect 0x0 A_BT_TAB_DIALOG*
m_TAB_Ext 0x0 A_BT_TAB_DIALOG_EXT*
m_console @0x555555c314f0 Console
m_mdiarea @0x555555c64250 QMdiArea
m_serial @0x555555cdddc0 QSerialPort
m_settings "SettingsDialog" SettingsDialog
m_settings_RFcomm 0x0 SettingsDialog_RFcomm*
m_status @0x555555c64370 QLabel
m_ui @0x5555556735a0 Ui::MainWindow_Bluetooth
mainAction @0x555555bd24c8 QAction*[16]
result "" QString
subAction @0x555555bd23c8 QAction*[16]
subMenu @0x555555bd2448 QMenu*[16]
text " Parent console (case 7) " QString
verify @0x555555bd2570 QStringList[16]
[children] <3 items> QList<QObject*>
[0] "qt_scrollarea_hcontainer" QAbstractScrollAreaScrollBarContainer
[1] "qt_scrollarea_vcontainer" QAbstractScrollAreaScrollBarContainer
[2] @0x555555c30e80 QWidget
[properties] <at least 8 items>
[methods] <14 items>
[extra]
[children] <6 items> QList<QObject*>
[properties] <at least 59 items>
[methods] <27 items>
[0] windowTitleChanged
[nameindex] 1
[type] signal
[argc] 1
[parameter] 149
[tag] 2
[flags] 6
[localindex] 0
[globalindex] 5
[1] windowIconChanged
[nameindex] 4
[type] signal
[argc] 1
[parameter] 152
[tag] 2
[flags] 6
[localindex] 1
[globalindex] 6
[2] windowIconTextChanged
[nameindex] 6
[type] signal
[argc] 1
[parameter] 155
[tag] 2
[flags] 6
[localindex] 2
[globalindex] 7
[3] customContextMenuRequested
[nameindex] 8
[type] signal
[argc] 1
[parameter] 158
[tag] 2
[flags] 6
[localindex] 3
[globalindex] 8
[4] setEnabled
[nameindex] 10
[type] slot
[argc] 1
[parameter] 161
[tag] 2
[flags] 10
[localindex] 4
[globalindex] 9
[5] setDisabled
[nameindex] 11
[type] slot
[argc] 1
[parameter] 164
[tag] 2
[flags] 10
[localindex] 5
[globalindex] 10
[6] setWindowModified
[nameindex] 12
[type] slot
[argc] 1
[parameter] 167
[tag] 2
[flags] 10
[localindex] 6
[globalindex] 11
[7] setWindowTitle
[nameindex] 13
[type] slot
[argc] 1
[parameter] 170
[tag] 2
[flags] 10
[localindex] 7
[globalindex] 12
[8] setStyleSheet
[nameindex] 14
[type] slot
[argc] 1
[parameter] 173
[tag] 2
[flags] 10
[localindex] 8
[globalindex] 13
[9] setFocus
[nameindex] 16
[type] slot
[argc] 0
[parameter] 176
[tag] 2
[flags] 10
[localindex] 9
[globalindex] 14
[10] update
[nameindex] 17
[type] slot
[argc] 0
[parameter] 177
[tag] 2
[flags] 10
[localindex] 10
[globalindex] 15
[11] repaint
[nameindex] 18
[type] slot
[argc] 0
[parameter] 178
[tag] 2
[flags] 10
[localindex] 11
[globalindex] 16
[12] setVisible
[nameindex] 19
[type] slot
[argc] 1
[parameter] 179
[tag] 2
[flags] 10
[localindex] 12
[globalindex] 17
[13] setHidden
[nameindex] 21
[type] slot
[argc] 1
[parameter] 182
[tag] 2
[flags] 10
[localindex] 13
[globalindex] 18
[14] show
[nameindex] 23
[type] slot
[argc] 0
[parameter] 185
[tag] 2
[flags] 10
[localindex] 14
[globalindex] 19
[15] hide
[nameindex] 24
[type] slot
[argc] 0
[parameter] 186
[tag] 2
[flags] 10
[localindex] 15
[globalindex] 20
[16] showMinimized
[nameindex] 25
[type] slot
[argc] 0
[parameter] 187
[tag] 2
[flags] 10
[localindex] 16
[globalindex] 21
[17] showMaximized
[nameindex] 26
[type] slot
[argc] 0
[parameter] 188
[tag] 2
[flags] 10
[localindex] 17
[globalindex] 22
[18] showFullScreen
[nameindex] 27
[type] slot
[argc] 0
[parameter] 189
[tag] 2
[flags] 10
[localindex] 18
[globalindex] 23
[19] showNormal
[nameindex] 28
[type] slot
[argc] 0
[parameter] 190
[tag] 2
[flags] 10
[localindex] 19
[globalindex] 24
[20] close
[nameindex] 29
[type] slot
[argc] 0
[parameter] 191
[tag] 2
[flags] 10
[localindex] 20
[globalindex] 25
[21] raise
[nameindex] 30
[type] slot
[argc] 0
[parameter] 192
[tag] 2
[flags] 10
[localindex] 21
[globalindex] 26
[22] lower
[nameindex] 31
[type] slot
[argc] 0
[parameter] 193
[tag] 2
[flags] 10
[localindex] 22
[globalindex] 27
[23] updateMicroFocus
[nameindex] 32
[type] <unknown>
[argc] 0
[parameter] 194
[tag] 2
[flags] 9
[localindex] 23
[globalindex] 28
[24] _q_showIfNotHidden
[nameindex] 33
[type] <unknown>
[argc] 0
[parameter] 195
[tag] 2
[flags] 8
[localindex] 24
[globalindex] 29
[25] grab
[nameindex] 34
[type] <unknown>
[argc] 1
[parameter] 196
[tag] 2
[flags] 2
[localindex] 25
[globalindex] 30
[26] grab
[nameindex] 34
[type] <unknown>
[argc] 0
[parameter] 199
[tag] 2
[flags] 34
[localindex] 26
[globalindex] 31
[extra]
data @0x555555c30fe0 QWidgetData
[children] <4 items> QList<QObject*>
[properties] <at least 2 items>
[methods] <7 items>
[extra]
[children] <8 items> QList<QObject*>
[properties] <at least 0 items>
[methods] <8 items>
[extra]
ConnectIndex 1 int
ConnectParent "MainWindow_Bluetooth" MainWindow_Bluetooth
ConnectText " TEST SettingsDialog Constructor (emit index 1 ) " QString
m_TAB_CommonDebug 0x0 A_BT_TAB_DIALOG*
m_TAB_Connect "A_BT_TAB_DIALOG" A_BT_TAB_DIALOG
m_TAB_Ext "A_BT_TAB_DIALOG_EXT" A_BT_TAB_DIALOG_EXT
m_currentSettings @0x555555d86c88 SettingsDialog::Settings
m_intValidator @0x555555dc61c0 QIntValidator
m_status @0x555555dc5af0 QLabel
m_ui @0x555555cb7d90 Ui::SettingsDialog
pTAB "A_BT_TAB_DIALOG" A_BT_TAB_DIALOG
staticMetaObject @0x7ffff7f03560 QMetaObject
statusBar @0x555555dd75f0 QStatusBar
text " this->parent()->objectName() " QString
Inspector
Expressions
"(?<=\thci0 <no such value>
// subMenu[index] = subMenu[index]
// ->addMenu(list[index] +
SERIAL_SETUP
SetupRun
endif
// //subtempmenu = new QMenu();
//
m_ui->actionConnect
processAction
qDebug().noquote() << text;
Return Value
Tooltip
|
|
|
|
|
There's probably a nice template way to do this. But if I understand you're problem, here's a simple C++ program with multi-level tree that you may be able to adapt to your situation:
#include <vector>
#include <iostream>
class Tree {
public:
int datum;
std::vector<Tree> children;
Tree(int d) :datum(d) {}
};
void walk(Tree& t, size_t n, void fn(const Tree& t, size_t n) )
{
fn(t, n);
for(auto child: t.children)
walk(child, n+1, fn);
}
int main()
{
Tree t(0);
for(int x = 1; x < 3; ++x)
{
Tree tmp(x);
t.children.push_back(tmp);
}
for(int y = 100; y < 500; y += 100 )
{
Tree tmp(y);
t.children[0].children.push_back(tmp);
}
walk(t, 0, [](const Tree& t, size_t indent) { std::cout << std::string(indent*3, ' ') << t.datum << '\n'; });
} This processes the parent before the children, but you can reverse the lines of the walk function to do the children first, if preferred. foreach is not part of the C++ standard, but the ranged for loop has been since C++-11, so your compiler almost certainly supports it. Whether QT containers will work with ranged for loops is not known to me. Still, the idea is the same. Create a recursive function that processes the parent, then calls itself on each of the children.
I'm sure there's a more generic way to do this using templates, that parameterizes the function, which would mean you don't have to write a separate walk function for every distinct function prototype on fn. Maybe that's an exercise you could undertake to help improve your understanding of templates, and other C++ facilities.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
modified 8-May-24 13:32pm.
|
|
|
|
|
Thank you.
I was hoping to build on my current knowledge and working code , regardless if it is standard or not.
I am looking into this
QTreeWidgetItemIterator<QAction*> it(parent<QAction*>(this));
and have two issues with it
I still cannot access the object "parent" and it looks as this class expects
tree widget to iterate.
Moore RTFM.
|
|
|
|
|
Salvatore Terress wrote: Moore RTFM
Correct
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
It worked...
I did save you a time to write FOUR letters...
Maybe I should end my post instead of
Cheers
( I hope you take this post as a joke ...good night from Huston )
|
|
|
|
|
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
|
|
|
|
|
POST voluntarily removed - no response
modified 9-May-24 10:43am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
