|
1) I don't have winrar installed on my computer (I'm at work)
2) I don't really want to dig into your code trying to understand what you did without any explanation.
You should be able to provide some relevant code snippet and explain clearly your problem. That's already a big step in understanding your problem and trying to solve it.
Remember that people here have limited time and are not getting paid.
|
|
|
|
|
|
Is there any way to create a memory device context that is valid between processes? If you do a HDC hdc = CreateCompatibleDC(...) its returning a pointer that's valid only for the current process address space. However, considering that DLL's can designate blocks of memory that are shared between processes, it seems you could have a mem DC shareable between processes as well.
|
|
|
|
|
An HDC is only valid within the context of the process that created it.
You can share the handle in a shared data segment but that won't make it
valid to another process.
What part(s) of the device context are you looking to share between processes?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Mark Salsbery wrote: An HDC is only valid within the context of the process that created it.
You can share the handle in a shared data segment but that won't make it
valid to another process.
What part(s) of the device context are you looking to share between processes?
Just an HBITMAP, not fonts, or pens, etc. If one process does a hdc = CreateCompatibleDC(...) and SelectObject(hdc,hbmp), I want any other process to be able to BitBlt to/from it.
This hdc is part of a C++ object I have defined in a shared memory segment of a DLL:
G g_list __attribute__((section ("shared"), shared));
So, every process that accesses that DLL is accessing the exact same g_list and g_list members. The class doesn't contain pointers, with the exception of this hdc which I didn't realize was a local pointer.
|
|
|
|
|
Force Code wrote: Just an HBITMAP
Sharing pointers between processes is a no-no, you need to share the data. In this case that data is called a "dib section".
Waldermort
|
|
|
|
|
I was going to suggest the same thing as WalderMort -
A DIB section through a named file mapping (in-memory).
All the info you need to create the DIBSection and a
memory DC in the second process can be shared.
See CreateDIBSection()[^].
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: I was going to suggest the same thing as WalderMort -
A DIB section through a named file mapping (in-memory).
All the info you need to create the DIBSection and a
memory DC in the second process can be shared.
See CreateDIBSection()[^].
We must be looking at documentation near simultaneously, somehow. I saw the file mapping thing but ruled it out as too byzantine (for my tastes).
What I did instead was to make hdc static in the class - which results in each process having its own copy - strangely. Since the class is in shared memory, making it nonstatic means every process has the same copy - static results in the opposite in this case. Then I have another new static member local_cnt. if local_cnt != (nonstatic)cnt then the static hdc is deleted and recreated (thus synchronizing with changes elsewhere.
|
|
|
|
|
Force Code wrote: What I did instead was to make hdc static in the class
And in a few weeks you will be asking why your code is crashing unexpectedly.
Waldermort
|
|
|
|
|
...or days 
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I have a dialog, on which CStatic frame is present.
I display the image on CStatic.
I want to move the image with arrow keys. The image moves nicely. but previous part of image is not getting erased. When i minimize and maximize the dialog, the back stuff get erased and only the image is visible.
Hi this is SHivraj
|
|
|
|
|
shivrajbhosale wrote: but previous part of image is not getting erased
Why would it get "erased" if you aren't erasing it?
The control handles its drawing. When drawing your image, you are
responsible for drawing and erasing.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Yes, you are right. Thats why i am calling Invalidate() of CStatic, which should redraw the whole control. But it does not invalidate() the region where the previous image was.
Thanks
Hi this is SHivraj
|
|
|
|
|
That was my point. The static control, depending on it's style, may only draw a frame.
It may not draw anything at all.
As suggested on another post here, you need to invalidate the appropriate window.
Yes, flicker is an issue - you should only invalidate the areas you want "erased",
not the entire dialog.
Static controls were not meant for imaging. If you want this behavior then you need to
make the control owner-drawn and implement this yourself. Better yet, implement your
own control class.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Why you dont use of a static control for show image and move it?
|
|
|
|
|
Sorry, i m not getting you.
The problem is, i am using CStatic for dispalying image, and invalidating it. Though it does not erases the whole CStatic.
|
|
|
|
|
try this
call
Invalidate( TRUE );
after moving your image
by this function the dialog box will repaint so problem will be solve.
plz reply if anything goes wrong.
Thank You.
hiren thakkar
|
|
|
|
|
Thanks for reply,
Invalidate( TRUE );
Will invalidate the Dialog. and that causes flickering. So thats why i am calling Invalidate() of CStatic(image is on this CStatic).
Hi this is SHivraj
|
|
|
|
|
shivrajbhosale wrote: Will invalidate the Dialog. and that causes flickering.
The dialog - especially the part of the dialog known as "the place where the Static control used to be" - is the bit that needs to be repainted. Invalidating the Static control isn't gonna do anything for it... since, as you may have noticed, the Static control isn't there anymore.
You can probably get by with calling InvalidateRect() on the dialog, specifying the area formerly occupied by the control. If you set the WS_CLIPCHILDREN style on the dialog, it'll even avoid drawing over the overlapping parts of the Static control (which is fine, unless that control or others use the WS_TRANSPARENT style...).
Frankly, i doubt there's much value in using a Static control for this purpose - it's one thing if you're just trying to display an icon or something as a fixed part of the dialog, but if you're gonna be doing anything non-trivial you might as well go all-out and render onto the dialog directly. Or create a custom control.
every night, i kneel at the foot of my bed and thank the Great Overseeing Politicians for protecting my freedoms by reducing their number, as if they were deer in a state park. -- C hris L osinger, Online Poker Players?
|
|
|
|
|
I am creating 3 tabs and each tab will have identical controls, but will show different information in the controls. Actually the only controls on each tab is a list control and a button.
I would like to use the same class on all three tabs. This class is based on a dialog resource in the resource editor. Is this even possible? Or does each tab need to be a different dialog class? When I attempt to use the same class, the tabs initially show up ok, but when I switch between tabs, the list control is hidden. It actually flickers for a second when I switch to the tab as though it will appear and then it is hidden again. I know there are probably not very many instances where you would want the same class on multiple tabs, but since the controls and behavior are the same -- just the data that is shown is different, it makes some sense in this case. Has anyone tried to do this before? I can't find anything on any searches.
I'm using VC6, and I'm actually using the CodeJock third party tab control, but I don't think that control is the problem. And if it works with the regular MFC tab control, I would just use it.
Thanks,
Izk
|
|
|
|
|
You could use 3 instances of the same dialog.
CYourDialog m_Tab1Dialog;
CYourDialog m_Tab2Dialog;
CYourDialog m_Tab3Dialog;
and switch between them
|
|
|
|
|
That's what I'm trying to do, but it doesn't seem to work. Instead when I switch tabs, the dialog goes blank. I think the problem might be that both tabs point to the IDD_INVITATION_LIST_VIEW resource, so when the tab control tries to hide/show the items, it can't hide/show the right ones (because they're the same resource). Does that sound at all correct, or way off?
Header File:
VInvitationListView m_historyListView;
VInvitationListView m_patientListView;
CPP File:
if (m_historyListView.Create(IDD_INVITATION_LIST_VIEW, &m_TabControl) == FALSE)
{
//Log Error and return
}
m_historyListView.ShowWindow(SW_SHOW);
CString str("History List");
m_TabControl.InsertItem(0, str, m_historyListView.GetSafeHwnd());
CXTPTabManagerItem* tab = m_TabControl.GetItem(0);
tab->SetData(eInvitationsTab);
m_TabControl.SetSelectedItem(tab);
m_TabControl.Reposition();
Elsewhere in same CPP File (I only add the second tab in certain scenarios):
if (m_patientListView.Create(IDD_INVITATION_LIST_VIEW, &m_TabControl) == FALSE)
{
//Log Error and return
}
m_patientListView.ShowWindow(SW_SHOW);
m_TabControl.InsertItem(1, sFullFormattedName, m_patientListView.GetSafeHwnd());
CXTPTabManagerItem* tab = m_TabControl.GetItem(1);
tab->SetData(ePatientSpecificTab);
m_TabControl.SetSelectedItem(tab);
m_TabControl.Reposition();
Izk
|
|
|
|
|
Just wanted to follow up and say that I think the problem was the code jock (3rd party) tab control being used after all. I ended up using the CXTTabCtrl instead of the CXTPTabControl. Instead of using the "InsertItem" method, I used "AddControl" and now the tabs seem to work just fine even though they both show the same class (separate instances).
Izk
|
|
|
|
|
Upon further review, CXTPTabControl works just fine. The solution to using the same dialog resource multiple times is to do the following on the create:
m_historyListView.Create(VInvitationListView::IDD, &m_TabControl)
m_patientListView.Create(VInvitationListView::IDD, &m_TabControl)
instead of:
m_historyListView.Create(IDD_INVITATION_LIST_VIEW, &m_TabControl)
m_patientListView.Create(IDD_INVITATION_LIST_VIEW, &m_TabControl)
I don't know the reasoning here, but I think using ::IDD allows the enum to give the windows different resource IDs or control IDs or something. Anyway, lesson learned for me and hopefully it helps someone else. I still think this is at least somewhat related to MFC/VC++ and not just the third party control. Although I never tried it with the standard CTabCtrl to be sure.
Izk
|
|
|
|
|
I'm working on a C project, but all my experience is with C++. Any recommendations for a good C website? Preferably with a good, active community like CodeProject's for questions I might have.
Thanks
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
