|
Well,
Just a few years ago my advice would be to use WinDbg and inspect the message queue. However believe it or not many of those fields have been removed from the public symbols on Windows 8.1 and above. Welcome to the age of security via obscurity.
The queue to nowhere
You could probably add some temporary debug code that checked for the ERROR_NOT_ENOUGH_QUOTA and responded by hooking the window and empty the queue by looping a call to the GetMessage function and dumping/printing all of the messages. Or maybe just call GetQueueStatus function and get an overview.
Best Wishes,
-David Delaune
|
|
|
|
|
I am posting this here because I had no luck elsewhere.
Since it is really NOT C/C++ question I like to provide details when somebody
answers. I have high regards for this forum , but from experience elsewhere I hesitate to waste forum and mine time with details and then get no response.
I hope it is understandable and nobody takes an offense.
I like help with analysis of this call, starting with the "command" macro.
I have basic understanding of ioctl and I am successfully implementing this call to send data.
I am unable to receive data and like to go thru the command macro expansion to gain understanding how it supposedly works. Since the main macro expands to more macros and I get lost...
Again - I'll provide details / links etc. to whomever responds.
Cheers
Vaclav
ret = ioctl(fd, SPI_IOC_MESSAGE(1), &tr);
|
|
|
|
|
What is to know it is obvious what it is and does .. it writes an SPI block command field index 1 (rx_buf), to the SPI driver.
I would also warn you that macro uses sizeof struct spi_ioc_transfer and it can not be used raw in a C++ program .. it will fail dramatically.
This is mandatory if you wish to use that header in C++ as that is a linux C base file.
extern "C" {
#include <linux/spi/spidev.h>
}
The alternative is to change the header file, you did this dance earlier.
This is one of those things when you start mixing C++ and C, C is it's own language and is not 100% compatible with C++ which has gone it's own way with some syntax. They are getting less and less compatible and so the general recommendation is compile C files with a C compiler and bring them in at the link stage. Other than that take a lot of care with C header files.
In vino veritas
modified 18-Dec-18 12:19pm.
|
|
|
|
|
Thanks Leon,
I have no issue writing the data. I just do not get how the initial command gets to read the data.
However, I just discovered that I can use Eclipse to step thru the macro.
But that is now immaterial since another "discovery" uncovered that I am coding for SPI and the hardware is set for 3 or 4 wire "serial communication" not even close to SPI.
I think I'll shelve the local LCD/TFT and start coding for remote - bluetooth - keyboard and real monitor.
Maybe some day I'll find small LCD/TFT with REAL SPI and not these "cellphones" surplus modules I have been fighting with.
Subject temporary inactive.
Have a great summer down under. We are freezing in Huston!
Cheers
Vaclav
|
|
|
|
|
When you get back if it isn't SPI (which is both 3 and 4 wire BTW) it will be MIPI display interface.
Drivers again in the linux driver
Display Serial Interface - Wikipedia[^]
In vino veritas
|
|
|
|
|
Sure, add another way to do it.
Than I'll have to buy a LCD with matching connector...
Fun.
|
|
|
|
|
You did not mention what compiler you are using, but with VC++, there is the /P option that will expand all preprocessor directives into a separate .I file that you can then look at. That would be the best way to see the final result of all the preprocessor "replacements."
"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
|
|
|
|
|
Using "plain" GCC++. I'll try the /P option and will report the results if necessary.
|
|
|
|
|
Please suggest me with ideas and code to place a dialog bar in the middle of a window.
|
|
|
|
|
|
Thanks for the reply. Which function is used to reposition the dialogbar.
SetWindowPos is not making any changes in the position for the dialogbar.
Please advice.
|
|
|
|
|
|
It's not doing any changes.
m_SysWnd.MoveWindow(100,100,100,100,true); //New positions
Am I missing anything?
|
|
|
|
|
manoharbalu wrote:
Am I missing anything?
Without seeing all the relevant code, we would be guessing at best.
What is m_SysWnd? Where are you calling MoveWindow() from?
"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
|
|
|
|
|
I have just run a simple test and it works fine. The only difference is that I am using basic Win32 rather than MFC.
|
|
|
|
|
Here is what I have:
RECT rectParent, rectDialog;
SIZE sizeParent, sizeDialog;
POINT point;
GetWindowRect(hDialog, &rectDialog);
sizeDialog.cx = rectDialog.right - rectDialog.left;
sizeDialog.cy = rectDialog.bottom - rectDialog.top;
GetClientRect(GetParent(hDialog), &rectParent);
sizeParent.cx = rectParent.right - rectParent.left;
sizeParent.cy = rectParent.bottom - rectParent.top;
point.x = (sizeParent.cx - sizeDialog.cx) / 2;
point.y = (sizeParent.cy - sizeDialog.cy) / 2;
ClientToScreen(GetParent(hDialog), &point);
MoveWindow(hDialog, point.x, point.y, sizeDialog.cx, sizeDialog.cy, true);
modified 18-Dec-18 12:39pm.
|
|
|
|
|
Thanks for your reply. I have changed the same code which you had sent to MFC as shown below. But still its not working. Please help me what is wrong..?
// MainFrm.h
CSysWindow m_SysWnd; //CSysWindow derived from CDialogbar
// MainFrm.CPP
int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
if (!m_SysWnd.Create(this, IDD_SYS2,CBRS_TOP|CBRS_FLYBY|CBRS_TOOLTIPS, IDD_SYS2))
{
TRACE0("Failed to create DlgBar\n");
return -1; // fail to create
}
m_SysWnd.SetBarStyle( m_SysWnd.GetBarStyle()|
CBRS_ALIGN_TOP|CBRS_BORDER_TOP | CBRS_FLOAT_MULTI );
m_SysWnd.AttachCtrls(); //To Attach the Combo box to the control bar window
RECT rectParent, rectDialog;
SIZE sizeParent, sizeDialog;
POINT pointNew;
HWND hDialog = m_SysWnd.m_hWnd;
CWnd * hParentWnd = m_SysWnd.GetParent();
// get the size of the dialog
m_SysWnd.GetWindowRect(&rectDialog);
sizeDialog.cx = rectDialog.right - rectDialog.left;
sizeDialog.cy = rectDialog.bottom - rectDialog.top;
// get the size of the parent Window's client area
hParentWnd->GetClientRect(&rectParent);
sizeParent.cx = rectParent.right - rectParent.left;
sizeParent.cy = rectParent.bottom - rectParent.top;
// parent's sizes minus dialog's sizes divided by 2
// give the coordinates of the centre position
pointNew.x = (sizeParent.cx - sizeDialog.cx) / 2;
pointNew.y = (sizeParent.cy - sizeDialog.cy) / 2;
// we need to make parent coordinates relative to the screen
hParentWnd->ClientToScreen(&pointNew);
// now move the Window to the new position
m_SysWnd.MoveWindow(pointNew.x, pointNew.y, sizeDialog.cx, sizeDialog.cy, true);
|
|
|
|
|
MFC handles the docking state and sizing of control bars.
Your code does not show that you are docking the control bar; are you?
After creation of m_SysWnd:
m_SysWnd.EnableDocking(CBRS_ALIGN_ANY);
EnableDocking(CBRS_ALIGN_ANY); // CMainFrame enable docking
DockControlBar(&m_wndDlgBar); // CMainFrame dock control bar
As far as moving the bar to a specific location look at CMainFrame::FloatControlBar()
which undocks the controlbar and allows for positioning.
FloatControlBar(&m_SysWnd,CPoint(100,100));
In regards to resizing the bar, you will probably have to provide some implementation of
CDialogBar::CalcFixedLayout() or CDialogBar::CalcDynamicLayout() override which provides size info.
CSize CSysWindow::CalcFixedLayout(BOOL bStretch, BOOL bHorz)
{
if (bStretch) // if not docked stretch to fit
{
// This is a fixed size. You will have to provide your own implementation.
return CSize(100,100);
//return CSize(bHorz ? 32767 : m_sizeDefault.cx,
// bHorz ? m_sizeDefault.cy : 32767);
}
else
return m_sizeDefault;
}
A Google search on these functions may help.
Best regards.
-- modified 19-Dec-18 7:02am.
|
|
|
|
|
Sorry, this is the correct code:
CSize CSysWindow::CalcFixedLayout(BOOL bStretch, BOOL bHorz)
{
if (bStretch) // if not docked stretch to fit
{
return CDialogBar::CalcFixedLayout(bStretch, bHorz);
}
else
// This is a fixed size. You will have to provide your own implementation.
return CSize(100,100);
}
|
|
|
|
|
Thanks for your kind reply.
Please help me to create a single window that has the following in the client area:
1. Dialog bar on top (used as a toolbar)
2. A view to display a graph trend (Updated every cycle)
3. After the above view, a Dialog bar to be placed. (Used as a tool bar)
4. A Grid control to display set of values which will be updated every cycle.
As I am not an expert into this, Please guide me steps to create the above window and update it every cycle as defined.
|
|
|
|
|
Sorry, the group does not write code for you. See How to Ask a Question at the top.
If you are not familiar with these tasks, you need to get training on programming in MFC.
I've learned a lot just by using Google to search for tasks I want to perform in MFC and
in many cases finding example code that helped me get the task done. If you write code to
perform a task and it doesn't work as expected, then ask the group for help with the
particular section of your code that isn't working and they will help you; like you did with
your current question.
Best regards
|
|
|
|
|
Sorry for that. As you said I will refer google. Thanks
|
|
|
|
|
I cannot see anything obvious in your code, although you may need to put that code at a later point; perhaps in the toolbar's OnCreate method. Looking at the documentation it suggests that a CToolBar should include the WS_CHILD style at creation, but you do not include that. Unfortunately I do not use MFC so I cannot recreate your situation.
If it still does not work then you will need to use your debugger to see what is happening.
|
|
|
|
|
My task is to make a function to append int to char*, using C style and end up with char*. No string etc.
I have it partially figured out - see attached code.
I have some understanding how passing by value works, but not sure how to actually code / use the strcat - the "all concatenated / done " part and use it in main code.
<pre>
char * CLASS_LCM1602::BuildMessage(char *&title, int value) {
char buffer[100];
snprintf(buffer, sizeof(buffer), "%d", value);
#ifdef DEBUG
cout << " conversion int to char buffer " << +buffer << endl; #endif
char FullMessage[100];
strcpy(FullMessage, title);
cout << "title copy " << FullMessage << endl;
strcat(FullMessage, buffer);
cout << "full message " << FullMessage << endl;
this is where I need some help
this does not makes sense to me
it compiles , does not execute
strcpy(title, FullMessage);
cout << "title " << title << endl;
exit(1);
return FullMessage; }
The function call
<pre>
char *title = "NEW TEST";
int value = 100;
char *message = i2c.BuildMessage(title, value);
here is the desired result code
never gets here
cout << " pass full message "<< +title << endl;
#endif
Any ( factual ) help will be appreciated.
Cheers
Vaclav
|
|
|
|
|
Please state clearly what are your requirements: you wrote
Quote: y task is to make a function to append int to char*, using C style and end up with char*
but then you are using C++ stuff and the snprintf, strcopy, etc. functions.
In a pure-C approach you have (basically) two alternatives:
- Passing a buffer containing the source string, but also large enought to contain the target one.
- Pass only the source string, and return a freshly allocated buffer containing the target one. Then it is caller task to eventually release the memory.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
