That I can help you with :-) CListCtrl::EnsureVisible makes a specified item visible. CListCtrl::Scroll gives you more control over how the list control's view is altered.
nobaq wrote:
First it was just a member variable of my CDocument but now I need the object in many places in my app.
That's what the GetDocument() method is for.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
One other thing - have you profiled the code to see what is slowing it down? I'd suggest implementing a virtual list control that just displays the numeric index of the list rows, to convince yourself that you've got the virtual list control set up correctly. Then work out how much of the SQL query you can do without taking too much time, and you can try to merge that into the list control implementation?
I confess I have not printed from an HtmlView, so take my logic with some skepticism. From the docs: Executes a command on an OLE object and returns the status of the command execution using the IOleCommandTarget interface. It does not say "queue up some thready thing". So S_OK, means the job is *done*. Iain.
The problem was not the browser control itself but my async pluggable protocol! I missed to handle PARSE_SECURE_URL for the secure manager so two different URLs in my protocol were essentially in a different domain. So I got "permission denied"-messages when accessing different frames (cross frame scripting prevention) Regards, Niki
See XCrashReport : Exception Handling and Crash Reporting - Part 4[^] if its helpful for you.
Of one Essence is the human race thus has Creation put the base One Limb impacted is sufficient For all Others to feel the Mace (Saadi )
Thank you, I think this is exactly what I was looking for :-) I'm inside my view anyway, so
this->OnCmdMsg( ID_FILE_PRINT, 0, 0, 0 );
does exactly what I want :-) Regards, Niki
My problem was that I have overwritten my hWnd variable and so these two handles were the same. And I was sending WM_COPYDATA to my own window. Stupid :-( But I have a much better solution now: http://www.codeproject.com/script/Forums/View.aspx?fid=1647&msg=2859334[^]
I HAVE THE SOLUTION!!! The DLL is loaded into the same address space of my application!! So I can just use pointers in normal WM_USER messages and I do not need any IPC!! :) And the best thing: I do not need synchronizing; this is done automatically: I just send a WM_USER with SendMessage to my view window which reads the data from the database and passes a pointer to that data to the DLL. The good thing: SendMessage is blocking while this is done so I do not need to lock my database variables with critical sections. And if there is another request in parallel, it is spooled automatically by the windows messaging system and SendMessage is blocking again. Please correct me if I am wrong. Regards, Niki