|
The main Application/UI thread is not blocked, I can still interact with it and manually stop the worker thread.
The message is to trigger a function in the MainFrame that will set an event (SetEvent).
The handler for the MESSAGEID id is never called. (breakpoint never triggered); so the event is never triggered.
(I know the INFINITE is not the best idea, but it is approved)
My pseudo-code is something like that :
Worker Thread:
void f(CWnd* p)
{
p->PostMessage(MESSAGEID, 0, 0 );
const DWORD dwEvent = WaitForMultipleObjects(NB_EVENT_REGISTERED, ghEventList, FALSE, INFINITE);
}
Main UI thread.
ON_MESSAGE(MESSAGEID, OnMESSAGEID )
LRESULT CMainFrame::OnMESSAGEID (WPARAM wParam, LPARAM lParam)
{
SetEvent(ghEventList[0]);
}
I'd rather be phishing!
|
|
|
|
|
See PostMessageA function | Microsoft Docs[^] for details of this error. Itmay be that something in your code is getting in a loop under certain conditions. Use your debugger to find the culprit.
|
|
|
|
|
i am not certain what to look for in the debugger.
That's my problem. 
I'd rather be phishing!
|
|
|
|
|
You need to add some debug code to check every time you call PostMessage.
|
|
|
|
|
Yes, that's what I thought.
I'd rather be phishing!
|
|
|
|
|
I love you. (in a completely professional way).
Merry Christmas.
I'd rather be phishing!
|
|
|
|
|
Ooh, that's a bit unexpected. 
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
