wxDataViewCtrl and DnD - c++

I am using wxWidgets 3.0.2 with Gtk on Linux.
I am trying to make a wxDataViewCtrl a drop target for a drag and drop operation. I derived a class from wxTextDropTarget and then made a call to wxDataViewCtrl::SetDropTarget() to make an instance of this class to be the drop target for the wxDataViewCtrl.
However, nothing happens. Every time I try to drop something on the wxDataViewCtrl, the wxDropSource::DoDragDrop() method returns wxDragCancel. For my custom wxTextDropTarget class, I overrode the OnEnter() method and had it write to stdout "OnEnter()" whenever I entered the wxDataViewCtrl with something to drop, but nothing gets written to stdout.
To test that I am even doing the custom wxTextDropTarget class right and setting up the drop source correctly, I added a wxTextCtrl to my GUI and made that the drop target and everything worked as expected: wxDropSource::DoDragDrop() returned wxDragCopy and "OnEnter()" would get written to stdout when I entered the wxTextCtrl with something to drop.
Does wxDataViewCtrl not support DnD? Or is there something else I am overlooking?

Just thought I'd follow up on my own post in case somebody else runs into the same problem.
After writing a small test program just to test DnD between a control and a wxDataViewCtrl and discovering that it works fine, I went back to my original application and stared at it for a bit longer to try and figure out what was I was doing differently. It turns out that I needed to call SetDropTarget() on the PARENT window of the target wxDataViewCtrl and not the wxDataViewCtrl itself, i.e. my_data_view_ctrl->GetParent()->SetDropTarget(blah blah blah);.
However, I didn't have to do this in my test program, so I thought it was a bit weird. The only difference between my test program and my actual program was that in my actual program, I have the wxDataViewCtrl inside a wxStaticBoxSizer and I think that was problem. I suspect that the wxStaticBox (that the wxStaticBoxSizer uses) was getting the drop notification instead of the wxDataViewCtrl, hence why I needed to set it's SetDropTarget() rather than the wxDataViewCtrl.

Related

How to programmatically print without prompting for filename in MFC and CView using Print-To-PDF printer?

I have a large graphics program using C++, MFC, and C++6.0.
I need it to print to PDFs without prompting the user for printer settings and file name.
I use CView::OnPrint() to print using Microsoft Print-to-PDF and it works fine except for the user prompts.
I've seen how to bypass those prompts with a PrintDocument object in C# but how can I do that when using CView::OnPrint() in MFC? Surely there must be a way?
My project is much too big to consider re-writing in C#, and I've tried moving forward to Visual studio 2005/2010/2019 etc. without success as changes in default data structure packing and converting existing data files is fraught with problems so solution has to be an addition to existing MFC C++6.0 if at all possible.
Can anybody help?
I haven't used VC++ 6 in quite a while now, so I'm going from rather distant memories, but the general idea is fairly simple.
Full Approach
Your view has a DoPreparePrinting member function. By default, this creates a CPrintDialog object, then invokes the CPrintDialog's DoModal to show the print settings dialog. Eventually (but not in DoPreparePrinting, if memory serves) that CPrinterDialog's CreatePrinterDC will be called to (obviously enough) create a DC for the printer using the settings the user entered in the dialog.
To bypass the dialog, you can override DoPreparePrinting. That receives a pointer to a CPrintDialog. Since you don't want to show a print dialog, you obviously won't invoke its DoModal member. Instead, you'll fill in its DEVMODE and DEVNAMES structures for the printer and any settings you want. Then when CreatePrinterDC gets called, it'll use what you filled in without displaying the dialog.
My personal advice would be to do a run using the dialog under the debugger, then after the CPrintDialog's DoModal has returned, look through the DEVNAMES structure it returned. You may not need it, but I found the DEVNAMES structure a little confusing the first time I had to set it up on my own. The DEVMODE is bigger and arguably more complex, but I've usually just modified a few bits and pieces, and left most of it with default values.
Simplified Approach
If you just want to use the system's default print settings, there's a simpler approach: you can override OnPreparePrinting. This receives a pInfo parameter, which is a pointer to a CPrintInfo. That has an m_bDirect member, which you can set to true to do "direct" printing, which just uses the default settings without using a printer dialog. I don't remember for sure when m_bDirect was added though. If it's missing, there's a "trick" to get the same effect: the default implementation of DoPreparePrinting doesn't display a print dialog for a print preview, so you override OnPreparePrinting to set m_bPreview to true, invoke DoPreparePrinting, then set m_bPreview back to false.

Can't reach newly made QLCDNumber

I was doing some testing with QTimer, within a bigger project, using Qt. I wanted to increment a value every 10 milliseconds and show that on the GUI.
void MainWindow::on_timeout(){
tmpValue++;
ui->testValue->display(tmpValue);
}
I copypasted a ui for a old project and added some of my own stuff.
I made the QLCDNumber testValue with a tag behind it saying the same. I expected to see the "testValue" int increase quickly but it did nothing. the weird part is when I replace the
ui->testValue->display(tmpValue);
with
ui->lcdThreshold1->display(tmpValue);
It worked as intended, but of course not with the QLCDNumber I wanted
this works for all QLCDNumbers that I have created in the past, just whenever I add a new one it does not work.
Some things worth noting are that it builds and runs without a problem. Also the "lcdThreshold1" from earlier is red the Qt editor, just like the "ui" bit. Whenever I put the new QLCDNumber there, like "testValue", it stays black and is not a option on the autocomplete.
Thanks in advance for your time!
pastebin of the xml file

QTest is not showing dialogs

Qt 4.7.1
I have a qttest setup which has until recently been performing well. I have encountered, and dealt with, the need to interact with modal dialogs by using singleshot timers.
However, I am now seeing the opposite behaviour; calls such as QFileDialog::getSaveFileName are returning straight away with no display of the dialog. This is since I performed a merge so I assume there is some code or build change behind it, but it isn't the function call itself.
As far as example code goes, I can't post my whole framework or AUT but the consider the following inside a test function:
QMessageBox::StandardButton button = QMessageBox::question(NULL,"Thing",
"Do you want to do a thing?",
QMessageBox::StandardButton::Yes | QMessageBox::StandardButton::No);
The call returns straight away and button is set to NoButton. I should add that there is a bit of a framework around my tests and I manually start each test with QTest::qExec. (The framework has not changed, of that I'm sure)
Any ideas on what might be causing this?
Edit:
The eventloop started by the messagebox in the above example has quitNow set to true, which is causing exec to return straight away. I'm now looking for why this is set, in the meantime feel free to enlighten me!
This was due to calling qApp->exit() in my cleanup() function. There is no need to do this!

C++ wxWidgets Gui-App stays in memory after closing it

The subject says it all. After i closed my app, it stays in the list of processes with some memory. I tried google perf tools and hours of debugging to find the leak.
Are there other tools to test it and find the problem?
Thank you.
My guess is that you have closed the top level window, and thus all its child windows, but you have not closed the app itself.
This does not happen if your program is arranged in a 'normal' way, but if you have, deliberately or by accident, used an unusual arrangement this can happen.
Fixing it, of course, depends on how exactly you have arranged your code. However, here is a suggestion to begin.
The usual way to close the app is to call wxApp::OnExit() which normally occurs when the top level window closes.
Do you have your own class, derived from wxApp? Do you have an override of OnExit()? If not, then make it so and use the debugger to check whether or not it is being called. If it is not being called, work out how to ensure that it is called.
Another idea: use the following to check that your top level window will close the app
bool wxApp::GetExitOnFrameDelete() const
Returns true if the application will exit when the top-level window is
deleted, false otherwise.
If this return false, use the corresponding set to make it so.
A 3rd idea: The application will not exit while there are any top level windows open. So perhaps you have another top level window that is minimized or invisible but has not been closed? Any wxDialog or WxFrame or window derived from these is a top level window and will prevent the application from closing.
A 4th idea: Do you have any globals or attributes of the application object, whose destructors could enter an endless loop? These destructors are called after the windows are destroyed and if one of them does not return you would see the behaviour you describe.
You may try to look at wxWidget's sample folder. You'll find lots of small but complete applications that contain the full init/exit application cycle.
Inspect some samples and compare with your app's workflow.
Yes...problem solved. A TopLevelWindow that was not destroyed. A Memory Leak....stupid mistake.

How do I setup a callback mechanism for RichEdit in win32

In win32, how do I setup a callback mechanism for RichEdit I have not created myself?
PART 1
I'm reading from a textedit field in another application's GUI. This works just fine now, except after the first read I'd like to fetch only new or modified lines. In GTK+ or Qt I'd just install a callback on some signal the field edits when its changed, but how does it work on Win32?
My MSDN searches result with nothing useful, probably because I don't know the exact term to search for. The class of the textedit is RichText20W, and it has some messages that are probably used somehow, though that article just discusses using them for the parent of the class.
PART 2
Also, if there is no such "text changed, here is the newly inserted text" callback which returns the new content immediately, I need some way to easily detect what is new. From top-of-my-head:
Have a marker at the end of the text block we've read, and only read between that and the end.
Store what we've read previously, and after a second read, remove the duplicate part from the latter to have the newly inserted stuff.
Option 2 might not be viable, since the textedit can contain any amount of text. The marker part sounds doable, but yet again, my feeble Win32 skills and horrible Win32 function names prevent me from finding the right way to do it.
Note that all these must be doable for a textedit I do not own and have not created, they belong to a third party process.
Code samples in C++ highly appreciated.
Disclaimer
Obviously, if there is some better way of doing it, let me know. I only assumed callback would be the way to go based on my previous experience with GTK+/Qt. Feel free to show me the path :)
Win32 controls don't work on message-specific callbacks that you can subscribe to. They just send messages to their parent window when something happens, in this case EN_UPDATE, EN_CHANGE and all that. Even these events don't tell you what text changed. They only tell you that it did change.
You could subclass the parent, but the documentation for SetWindowLongPtr explicitly says you "should not subclass a window class created by another process." Something like this is probably possible with hooks, but I haven't used them enough to say for certain how you'd actually do it.
I realize it's an old post, but this article seems to be doing something similar.
Based on Joel's answer, I quit looking for callbacks and just made a small class that hooks itself (not by a real API hook though) to the richedit and polls it once a second for content length, and if it has changed since the last poll, it asks for the content, compares that to previous known content and emits a signal with the changed content.
This seems to work OK for this purpose, but if someone knows a better way still (some real and tested way of doing it via API hooks or something), please post.