|
First of all I cannot use MFC.
I have made WM_MENUSELECT handling in the dialog:
case WM_MENUSELECT:
return OnMyMenuSelect(LOWORD(wpar), HIWORD(wpar), (HMENU)lpar);
However function IsMenu((HMENU)lpar) returns FALSE. Does anybody has idea why ?
|
|
|
|
|
NoviceEx wrote: However function IsMenu((HMENU)lpar) returns FALSE. Does anybody has idea why ?
Did you try to debug this function? This would allow you to know why it returns false.
noop()
|
|
|
|
|
The function I need to implement is to first select a row in the ListControl, and then press the "Import" button, the program will import the file corresponding to the pre-set corresponding path of this row.
I have written an import function, just need to provide the path and name corresponding to the file you want to import.
The problem is that I don't know how to match the selected line with the pre-set path and file, because there are too many files and paths (at least 20) to be set in advance, and listcontrol has the same number of lines and files as the number of files.
The point of my problem is that I don't know how to get the number of any selected row to associate it with the corresponding path and file.
All I know is to associate any row selected by the ListControl with only one of the specified paths and files.
Here are my codes:
void RobotmodelPre::OnBnClickedInputmodel()
{
CDocTemplate* pDocTempl;
POSITION pos=AfxGetApp()->GetFirstDocTemplatePosition();
pDocTempl=AfxGetApp()->GetNextDocTemplate(pos);
POSITION posDoc=pDocTempl->GetFirstDocPosition();
if (posDoc!=NULL)
{
m_pDoc=(CRobotAppDoc*)pDocTempl->GetNextDoc(posDoc);
}
else
{
m_pDoc=NULL;
AfxMessageBox("FAIL!");
return;
}
CString filePath1 = "D:\\robot_new\\Data\\4kg_simplified\\SR4_SIASUN.rbt";
CString folderPath1 ="D:\\robot_new\\Data\\4kg_simplified";
CWaitCursor cur;
XObject obj;
bool bIsRobotLoad = false, bIsObjectLoad = false, bIsWorkPieceLoad = false, blsToolLoad = false;
int iObjSize = m_pDoc->m_vObj.size();
int iRobot = -1, iObj = -1;
CMainFrame* pMainFrame = (CMainFrame*)AfxGetMainWnd();
if( m_pDoc->LoadRbt(filePath1,folderPath1))
{
bIsRobotLoad = true;
iRobot= m_pDoc->m_vRobot.size()-1;
pMainFrame->m_wndModelTreeView.DisplayRobotTree();
}
}
Among them, the "LoadRbt" function only needs to provide two parameters.
The debugging result of this code is that no matter which line is selected, the same file will be imported (the rbt file is a file I customize).
How can I select different lines and import different files?
|
|
|
|
|
You have hardcoded your file names instead of getting the selected item from the ListBox.
|
|
|
|
|
Is the path/file part of the ListControl contents?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
No,that is why I do not know how to code.
|
|
|
|
|
Then I would suggest calling SetItemData() after each item is added to the control. Then when an item in the list control is clicked, use the index/pos number provided to call GetIemData().
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
wow,thank you for your advice!I will try later!
I tried to solve the problem myself by means of using "CStringArray".But it fails when I debug and I do not know the reason.Would you please tell me the bug?
Here are the addition codes:
CStringArray filePaths;
CStringArray folderPaths;
filePaths.Add("D:\\robot_new\\Data\\4kg_simplified\\SR4_SIASUN.rbt");
filePaths.Add("D:\\robot_new\\Data\\IRB4400\\IRB4400 m.rbt");
folderPaths.Add("D:\\robot_new\\Data\\4kg_simplified");
folderPaths.Add("D:\\robot_new\\Data\\IRB4400");
CWaitCursor cur;
XObject obj;
bool bIsRobotLoad = false, bIsObjectLoad = false, bIsWorkPieceLoad = false, blsToolLoad = false;
int iObjSize = m_pDoc->m_vObj.size();
int iRobot = -1, iObj = -1;
CMainFrame* pMainFrame = (CMainFrame*)AfxGetMainWnd();
if( m_pDoc->LoadRbt(filePaths[nId-1],folderPaths[nId-1]))
{
bIsRobotLoad = true;
iRobot= m_pDoc->m_vRobot.size()-1;
pMainFrame->m_wndModelTreeView.DisplayRobotTree();
}
|
|
|
|
|
tianzhili4399 wrote: But it fails when I debug
What fails, what errors do you see, what is LoadRbt supposed to do?
|
|
|
|
|
thank you,I have debug successfully! 
|
|
|
|
|
I keep running into snags using Linux "autotools " generated code.
Would this work?
1. Build required C++ library on host architecture and link it to the "build" system?
I am successfully using Target Communication Framework - Agent - to "connect" from build system to host . Uses TCP.
I used "post-processing" long time ago and I was thinking if that or pre-processing could be used to "add" the library link before the main process is done. Just a thought.
I do not know to to "link" across network during program compilation / linking.
2. Could I just import / copy the correct architecture library from the host system to build system and just link it normally?
I am going to try "scp" Linux command to copy the C++ library from the host to build system.
Is there anything special why this "scp" copy would not work?
SOLUTION
Used option 2 - scp /rcp to copy library build on ARM system to similar folder on X86.
Linked to it the usual way. Linker accepted the file format , no problems.
Test run on ARM "host" and works as expected.
Cheers
modified 13-May-19 14:10pm.
|
|
|
|
|
It is not clear what the actual problem is, and why you cannot build the library in the same way that you build the rest of the system. Linking a library to an application should work if both sides have been built to the same target architecture.
|
|
|
|
|
help!
If making a non-static system, to direct feed at at static app. does the direct feed have to be captured simultaneously as the variable
|
|
|
|
|
Your statement/question is less than coherent. Can you reword it (and the subject) to make more sense?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
What on earth... 
|
|
|
|
|
|
I could use some assistance deciphering enclosed "make" output.
I like to start with "In file included..."
The last number is probably source line (?)
Does the sequence tells the "hierarchy " of the headers (?)
Is there a single source of error - "error: size of array" (?)
I am not asking for solution, I just need some guidance to logically analyze the output and correct the error.
Thanks
Cheers
Addendum
Does
/usr/include/glib-2.0/glib/gtypes.h:422:3: note: in expansion of macro 'G_STATIC_ASSERT'
G_STATIC_ASSERT(sizeof (unsigned long long) == sizeof (guint64));
tells me to look at definition of G_STATIC_ASSERT (?)
Do I understand correctly that notes " note:...." being added by make are not necessarily in some relation / sequence and can start debugging from any place?
jim@jim-desktop:/media/jim/DEV/BLUEZ/BLUEZ_RPI/bluez-5.50$ sudo make
make --no-print-directory all-am
CC lib/bluetooth.lo
CC lib/hci.lo
CC lib/sdp.lo
CCLD lib/libbluetooth.la
CC lib/uuid.lo
CCLD lib/libbluetooth-internal.la
arm-linux-gnueabihf-ar: `u' modifier ignored since `D' is the default (see `U')
CC gdbus/mainloop.lo
In file included from /usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h:9:0,
from /usr/include/glib-2.0/glib/gtypes.h:32,
from /usr/include/glib-2.0/glib/galloca.h:32,
from /usr/include/glib-2.0/glib.h:30,
from gdbus/mainloop.c:28:
/usr/include/glib-2.0/glib/gtypes.h: In function '_GLIB_CHECKED_ADD_U64':
/usr/include/glib-2.0/glib/gmacros.h:232:53: error: size of array '_GStaticAssertCompileTimeAssertion_0' is negative
#define G_STATIC_ASSERT(expr) typedef char G_PASTE (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1] G_GNUC_UNUSED
^
/usr/include/glib-2.0/glib/gmacros.h:229:47: note: in definition of macro 'G_PASTE_ARGS'
#define G_PASTE_ARGS(identifier1,identifier2) identifier1 ## identifier2
^
/usr/include/glib-2.0/glib/gmacros.h:232:44: note: in expansion of macro 'G_PASTE'
#define G_STATIC_ASSERT(expr) typedef char G_PASTE (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1] G_GNUC_UNUSED
^
/usr/include/glib-2.0/glib/gtypes.h:422:3: note: in expansion of macro 'G_STATIC_ASSERT'
G_STATIC_ASSERT(sizeof (unsigned long long) == sizeof (guint64));
^
Makefile:5858: recipe for target 'gdbus/mainloop.lo' failed
make[1]: *** [gdbus/mainloop.lo] Error 1
Makefile:3278: recipe for target 'all' failed
make: *** [all] Error 2
jim@jim-desktop:/media/jim/DEV/BLUEZ/BLUEZ_RPI/bluez-5.50$
SOLUTION FOUND
OK, against my better judgment , I just hate 'try this and see' ) I changed the cast to (unsigned long) and here are the abbreviated results :
jim@jim-desktop:/media/jim/DEV/BLUEZ/BLUEZ_RPI/bluez-5.50$ sudo make
make --no-print-directory all-am
CC gdbus/mainloop.lo HORRAY IT passed !
CC gdbus/watch.lo
CC gdbus/object.lo
CC gdbus/client.lo
CC gdbus/polkit.lo
CCLD gdbus/libgdbus-internal.la
arm-linux-gnueabihf-ar: `u' modifier ignored since `D' is the default (see `U')
............
CC client/gatt.o
CCLD client/bluetoothctl
/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lglib-2.0
/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find -ldbus-1
/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lreadline
collect2: error: ld returned 1 exit status
Makefile:4136: recipe for target 'client/bluetoothctl' failed
make[1]: *** [client/bluetoothctl] Error 1
Makefile:3278: recipe for target 'all' failed
make: *** [all] Error 2
jim@jim-desktop:/media/jim/DEV/BLUEZ/BLUEZ_RPI/bluez-5.50$
This last error is definitely telling "make" is attempting to cross compile ( client ) and looking for "arm" resources.
I'll work on that and ask for assistance if needed.
I really appreciate all the support with the last case.
I do not need to find out why the source code has a 64 bits bug in it.
Prefer not to fix somebody else working code.
I am trying hard not to screw something and break this "autotools" chain of command, so I'll be happy with this hack.
Thanks again
Cheers
modified 10-May-19 14:53pm.
|
|
|
|
|
It looks that the size of the unsigned long long provided by the platform you're (cross) compiling for, doesn't comply with the requested one (should be the same of guint64, that is 8 bytes).
|
|
|
|
|
You may be right, I found this definition:
guint64
typedef unsigned long guint64;
An unsigned integer guaranteed to be 64-bits on all platforms. Values of this type can range from 0 to G_MAXUINT64 (= 18,446,744,073,709,551,615).
To print or scan values of this type, use G_GINT64_MODIFIER and/or G_GUINT64_FORMAT.
Thanks
|
|
|
|
|
Am I on the right track ?
Apparently the type unsigned long long is not "typedef.
It also looks line 422 should not be used per comment note.
#ifndef _GLIB_TEST_OVERFLOW_FALLBACK
#if __GNUC__ >= 5
#define _GLIB_HAVE_BUILTIN_OVERFLOW_CHECKS
#elif __has_builtin(__builtin_uadd_overflow)
#define _GLIB_HAVE_BUILTIN_OVERFLOW_CHECKS
#endif
#endif
#define g_uint_checked_add(dest, a, b) \
_GLIB_CHECKED_ADD_U32(dest, a, b)
#define g_uint_checked_mul(dest, a, b) \
_GLIB_CHECKED_MUL_U32(dest, a, b)
#define g_uint64_checked_add(dest, a, b) \
_GLIB_CHECKED_ADD_U64(dest, a, b)
#define g_uint64_checked_mul(dest, a, b) \
_GLIB_CHECKED_MUL_U64(dest, a, b)
#if GLIB_SIZEOF_SIZE_T == 8
#define g_size_checked_add(dest, a, b) \
_GLIB_CHECKED_ADD_U64(dest, a, b)
#define g_size_checked_mul(dest, a, b) \
_GLIB_CHECKED_MUL_U64(dest, a, b)
#else
#define g_size_checked_add(dest, a, b) \
_GLIB_CHECKED_ADD_U32(dest, a, b)
#define g_size_checked_mul(dest, a, b) \
_GLIB_CHECKED_MUL_U32(dest, a, b)
#endif
/* The names of the following inlines are private. Use the macro
* definitions above.
*/
#ifdef _GLIB_HAVE_BUILTIN_OVERFLOW_CHECKS
static inline gboolean _GLIB_CHECKED_ADD_U32 (guint32 *dest, guint32 a, guint32 b) {
return !__builtin_uadd_overflow(a, b, dest); }
static inline gboolean _GLIB_CHECKED_MUL_U32 (guint32 *dest, guint32 a, guint32 b) {
return !__builtin_umul_overflow(a, b, dest); }
static inline gboolean _GLIB_CHECKED_ADD_U64 (guint64 *dest, guint64 a, guint64 b) {
G_STATIC_ASSERT(sizeof (unsigned long long) == sizeof (guint64));
return !__builtin_uaddll_overflow(a, b, (unsigned long long *) dest); }
static inline gboolean _GLIB_CHECKED_MUL_U64 (guint64 *dest, guint64 a, guint64 b) {
return !__builtin_umulll_overflow(a, b, (unsigned long long *) dest); }
#else
static inline gboolean _GLIB_CHECKED_ADD_U32 (guint32 *dest, guint32 a, guint32 b) {
*dest = a + b; return *dest >= a; }
static inline gboolean _GLIB_CHECKED_MUL_U32 (guint32 *dest, guint32 a, guint32 b) {
*dest = a * b; return !a || *dest / a == b; }
static inline gboolean _GLIB_CHECKED_ADD_U64 (guint64 *dest, guint64 a, guint64 b) {
|
|
|
|
|
The #defines above show that the offending function could (or should) have been invoked either through the alias g_uint64_checked_add() or g_size_checked_add(), but the latter only if sizeof (size_t) is 8 bytes. but that doesn't add any helpful information with respect to fixing the problem: that casting a guint64* to (unsigned long long)* is not a valid operation for the target system you are compiling for.
What is in line 28 in mainloop.c? Have you called g_uint64_checked_add() when you should have called g_size_checked_add instead? What are the types of the arguments you use in the function call?
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
|
G_STATIC_ASSERT(sizeof (unsigned long long) == sizeof (guint64));
The assert is telling you that the defined sizes of the guint64 and unsigned long long types are not the same, so the code cannot be built for the target that you are trying.
|
|
|
|
|
You have to interpret the error information back to front:
1. The make error
Vaclav_ wrote: Makefile:5858: recipe for target 'gdbus/mainloop.lo' failed
tells you that the target mainloop.lo could not be built, and the messages above are output from the compiler that was called in an attempt to build this target.
2. The compiler output gives you accurate information on how it tried to expand a macro, resulting in C code that doesn't compile, and why it doesn't compile (negative array index).
3 The last lines of the compiler output show the condition that is statically checked, and ultimately leading to the compile error: as already pointed out, apparently the type unsigned long long does not have the same size as guint64.
The output further above above shows how the static assert macro expansion turns the value of this condition (false) into an invalid array type definition, but that information is not neede or useful to you; you only need to know that an assertion failed, find out why this happened, and (how (or if) you can fix it.
4. The static assert was invoked in function _GLIB_CHECKED_ADD_U64, and this function was called somewhere in mainloop.c (in line 28, according to the compiler). That means you should check the function call: maybe you're calling the wrong function for the job. Or maybe you shouldn't use guint64 for the target system you're compiling for.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Thanks, this is exactly what I was asking for.
All I wanted to know was answered in your first line.
I certainly appreciate you taking the time to walk thru the process.
I forgot to stress - this is not my code - it is a product of "make" produced with the aid of "configure" script which is part of canned "bluez" source code.
The "configure" is optioned to build "C" library, not to install "bulez" package, for ARM architecture. The "configure" and associated processes ( make and make install) are run on X86 architecture - hence "the problem".
All of this is "created" by autotools.
So I need to be careful not to "disturb" the code created by autotools.
Some of the code has very noticeable notes that "it was created bu autotools" , hence do not mess with it.
Cheers
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
