Whoah! What happened to my Event handling? Topic is solved

[jmason1182]

This is a followup question to a different topic (found here:

http://forums.wxwidgets.org/viewtopic.p ... highlight= )

I have gotten my little "lock-out" timer and such to work. And it works well. But I was directed to use the wxApp::FilterEvent function to handle the global events to make it work. (See the other topic for what we did...)

BUT I have a lot of enhanced wxTreeListCtrl controls to display the information. Now, all the painting is messed up! Everytime I update the information in the tree, it does not update the UI until I use my mouse to manually drag a column wider. I can select on the tree, double-click... it all behaves fine... but I can't see anything but a blank control!

Any suggestions? I don't see anything that would affect the painting or updateUI events.... so why are they now affected?

[jmason1182]

Wow... I got a phantom email that said somebody replied... but there isn't one here.....

[Auria]

Wow... I got a phantom email that said somebody replied... but there isn't one here.....

I did, but i removed it because i realised i didn't really know this topic so my answer may not have been relevant
Sorry for the noise, hoepfully someone else will know

[jmason1182]

...i realised i didn't really know this topic so my answer may not have been relevant...

Wow. Thanks. It's not everyday you get honesty and integrity in a forum.

[upCASE]

Hi!
Just a wild guess: You do not return -1 in wxApp::FilterEvent().

I suppose you should to have the event processed normally, even if you processed it.

[jmason1182]

Here's my FilerEvent function. See if this helps the issue at hand....

Code: Select all

//Application wide event filtering - F1 and F2 are global
// mainframe dialogs (help and error log), and all keypresses
// and user input needs to reset the inactivity "lock" timer.
int Main::FilterEvent(wxEvent &event) {

	//capture all key events - Key presses
	if ( event.GetEventType()==wxEVT_KEY_DOWN ) {

		//Regardless of what key was pressed, we reset the
		// locking timer (keypress = NOT inactivity)
		mainFrame->LockTimerResetK((wxKeyEvent&)event);

		if(((wxKeyEvent&)event).GetKeyCode()==WXK_F1) {
			//F1 pressed - open help
			mainFrame->HelpKeyClick( (wxKeyEvent&)event );
			return true;
		}
		if(((wxKeyEvent&)event).GetKeyCode()==WXK_F2) {
			//F2 pressed - open main error log
			mainFrame->LogKeyClick( (wxKeyEvent&)event );
			return true;
		}

		//all other key presses we handle as normal.
		return -1;

	}

	//now we check for the mouse movement, clicks, etc. ALL mouse events (this is a range)
	if( event.GetEventType()>=wxEVT_LEFT_DOWN && event.GetEventType()<= wxEVT_MOUSEWHEEL ) {
		//User did SOMETHING, so we are not inactive, reset the lock timer.
		mainFrame->LockTimerResetM((wxMouseEvent&)event);
		//But we will allow the mouse "action" to be handled as normal.
		return -1;
	}


	//And lastly we check for any and all System messages that we want to exit from
	// SUCH AS logging out of the computer and shutting the computer down.
	if( event.GetEventType()==wxEVT_QUERY_END_SESSION ) {
		wxCloseEvent closeEvent(wxEVT_QUERY_END_SESSION, wxID_ANY);
		closeEvent.SetEventObject(this);
		closeEvent.SetCanVeto(false);

		this->ProcessEvent(closeEvent);
		return true;
	}

	//Allow the event to continue untouched.
	return -1;
}

And the update part of the wxTreeListCtrl comes from an EVT_COMBOBOX.... so it shouldn't even be filtered!

What am I missing?

[DavidHart]

Hi,

What am I missing?

Dunno. But I suggest you comment out random parts of your FilterEvent (or even all of it) to see which is causing the problem.

Regards,

David

[jmason1182]

OK.... so something went wrong....

I just commented out section by section, piece by piece, and then eventually the entire dang function. No go. The problem isn't in my filerevents function.

That means that somewhere I must have changed something else to make the control stop catching update events.

SO now my questions changes.... where should I begin looking? I've never been good with debugging events. This control is based on both a tree and a list, so the events for them are very similar.

Where should I start looking?

[DavidHart]

It's difficult to guess what would have changed it from working to not working; but try doing pTree->Refresh(), or pTree->Update(), or both.

[jmason1182]

OK so hopefully someone can give me a clue as to what is going on. I have been trying to contact the creator of this control, wxTreeListCtrl from www.twinforms.com and so far I can't get him to respond.

So can anyone give me a hand? Not one, but ALL of the instances where I use wxTreeListCtrl don't refresh their display. And rather to have to catch every change (it won't even show the highlight when I select a row until I click on the header) and call a refresh or something, I want help figuring out what is going on! Can anybody help me? Has anyone used the wxTreeListCtrl!?

[jmason1182]

OK, I found it. The wxTreeListCtrl uses the Idle events for some of its updates. That's what happened. I missed a line!

In my app, the refreshing BROKE after I began trying to get my "sleep lock" stuff working. I had originally tried to use the Idle Events. So, in my main app, I put:

Code: Select all

wxIdleEvent::SetMode(wxIDLE_PROCESS_SPECIFIED);

So, the wxTreeListCtrl's weren't getting any refreshes because they weren't getting the idle events!


So here's my generic "I learned something today:" Don't use things if you don't need to. If you do need to use the idle events for anything (like I was trying) DON'T FORGET TO PUT wxWS_EX_PROCESS_IDLE for all frames that stop working better yet, check to see if the idle events are needed first!

That should have been documented in the custom control somewhere.....

I gave you both assists for at least trying.

[DavidHart]

So here's my generic "I learned something today:"

I'm glad you got it working again, but a more-generic lesson is: Regularly (and incrementally) back up your source; especially before any major changes. That way you can easily revert to something that you know works, or diff to see changes.

If you don't want to use a local svn or similar, do dated archives.

[jmason1182]

You know what's funny is I do backups. Every day as I prepare to leave I do a full backup of the entire source structure. I was befuddled as to what the problem could be so I started doing diffs.... file by file... and that's when I found that SINGLE line I added.

If it weren't for my backups... I'd be up a creek.