|
YES. That works. Thank you.
cout << flush; also works in most cases, but apparently your way is better.
thanks
|
|
|
|
|
Iam using CDhtmlDialog class to display the images in a dialog window.It works fine .But the problem is that while displaying images ,it displays the images with a 10 ,20 pixel offset .ie. the image is displayed with a offset of 10 pixel from the window boundary .
I think this problem is something related to the IE .If u opena image in aIE ,the iE leaves a 10 X 20 offset for diplaying a image .
How can i avoid this ???
|
|
|
|
|
I got the answer too ..
CDhtmlDialog object
Object.m_pBrowserApp->get_FullScreen((VARIANT_BOOL *)TRUE);
sorry for bothering u guys
|
|
|
|
|
Hi all --
I want to create a shared memory allocator for STL containers, similar to the design employed in a recent issue of CUG, which had an article on doing such in Linux: http://www.cuj.com/current/?topic=current
In this article, a Factory pattern is used to construct an *entire* STL container in shared memory, which is exactly what I want to do, but I suspect the solution in this article is flawed. (If anyone has read this article I'd be curious to know if you came to the same conclusion.)
The reason it's flawed is because there is a tacit assumption that the virtual memory address returned by 'shmat' (roughly, the linux equivalent of the Win32 MapViewOfFile API) is the same across diff't processes.
I actually have no idea how safe this assumption is in Linux, but I know in Windows NT 4.0 that MapViewOfFile does tend to return the same address across processes for a given requested size when the WinNT paging file is used to back the virtual memory. But NT cannot guarantee this is true; therefore I cannot use MapViewOfFile. MapViewOfFileEx, on the other hand, lets the calling process request a particular starting virtual address, but if the process has already allocated any addresses in that range the call fails and returns 0, so this is not much better than MapViewOfFile as far as I can tell.
So my question is about the predictability of MapViewOfFileEx: who has experience with this (specifying a particular area in virtual memory)? How often and under what conditions does MapViewOfFileEx fail? I'm worried that relying on it would lead to an unreliable shared memory allocator, and yet I have no idea how often in practice people actually use this. Any thoughts, guidance here?
Many thanks,
Chris
|
|
|
|
|
clm wrote:
The reason it's flawed is because there is a tacit assumption that the virtual memory address returned by 'shmat' (roughly, the linux equivalent of the Win32 MapViewOfFile API) is the same across diff't processes.
I haven't read the CUJ article (yet) but I do have some experience with Memory Mapped Files. I do know that the address you get back from MapViewOfFile() differs on W98 and WXP for example. This is important where you use MMF as a persistant store with embedded memory addresses as it means the file isn't portable. I can't comment on requests for a specific address using MapViewOfFileEx() other than to say that again this won't work with the same address across W98 and WXP.
Why do you need the same address in different processes anyway?
For a simple example of my use of MMF see my mods to pugxml http://www.codeproject.com/soap/pugxml.asp[^]
If you want some references to MMF articles etc. let me know.
Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program
|
|
|
|
|
Hi Neville -
Thanks for your thoughts here -- your experience w/MMF is exactly what I wanted to hear (I read the specs on the relevant API calls from books and MSDN). It sounds like MapViewOfFile is out of the question for what I want to do, as I suspected.
Here is the reason why (ideally) the same address would be returned by MapViewOfFile in different processes:
Consider constructing a list<int> object in shared memory. The process that populates the (doubly linked) list creates nodes with pointers embedded in each node(*). These pointers are valid only in the process which created the list if the MVOF() return value differs between processes. So when a second process attaches to shared memory and accesses the linked list, it will immediately GPF (if we're lucky).
So I need the base address to be the same in different processes if I follow the type of solution in that CUJ article. In this implementation, the entire container is constructed in shared memory using a custom allocator, which manages a free list ('Chunks').
Of course, a workaround would be to add a level of indirection in the STL container implementations, so that offsets from a base pointer, not pointers, are cached. (MapViewOfFile return value is the base).
I'd be interested in any references to MMF articles you know -- feel free to email me, thank you very much.
-- Chris
(*) True for the VC6.0 and 7.0 STL implementations, at least.
|
|
|
|
|
|
Neville, thank you!! The links were great -- just the info I was looking for -- and the advice on using autopointers (storing offsets while supplying pointer semantics) was spot on.
This is definitely something I have a production need for, not an academic exercise. The CUJ article is in Apr 2003, unfortunately it apparently is not available on their website (I will email you about this).
Cheers,
Chris
|
|
|
|
|
Here is the example code.
class outer
{
class inner
{
outer* p_outer;
};
};
now in the constructor of inner class i need the pointer of outer.
Any idea on how this could be done?
|
|
|
|
|
outer::outer : inner (this)
{
}
That should work but there are some restrictions. Don't try to do anything serious with p_outer in inner's constructor. The instance of outer hasn't been fully constructed yet.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
It seems to give me pointer to inner, not pointer to outer class.
|
|
|
|
|
No, you are supplying the "this" pointer to inner's constructor from outer's constructor. Thus "this" points to outer.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Hi!
Following situation:
I've a very huge class with some arrays in it. Every user input I call the following function:
CMyClass GetByValue()
{
return m_Class;
}
Then:
void OnUserInput(...)
{
CMyDoc pDoc = GetDocument();
CMyClass cClass = pDoc->GetByValue();
//Some operations with cClass...
[...]
}
After a period of time the app slows down (because m_Class gets very big -> arrays inside it are filled)...
Is there a possibility to fast-copy a class? Or to fast-copy CArrays?
I can't use pointers cause' I need a COPY of m_Class -> the original m_Class should not be modified...
Build a system that even a fool can use, and only a fool will use it.
|
|
|
|
|
Assuming that you copy constructors aren't slow, then you have a basic design flaw in your software. You can't expect to make copies of huge amounts of data every time the user does something.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
I did not think it would take so long...
...the data is for my Undo/Redo...
Build a system that even a fool can use, and only a fool will use it.
|
|
|
|
|
Yeah, I had a feeling that was the case. I have done the same thing. The only real way to do undo/redo is to save delta's instead of complete copies of the data. It is more work, but well worth the effort.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
I think you're right,I will have to save deltas instead of the whole data. I summed everything my Und/Redo class needs, it's about 200kb, every click! So RAM gets filled with 200kb every time I get an user input, that's not good 
Build a system that even a fool can use, and only a fool will use it.
|
|
|
|
|
Jakob Bysewski wrote:
I can't use pointers cause' I need a COPY of m_Class -> the original m_Class should not be modified...
So, return a const reference. Like this:
const CMyClass &GetByValue()
{
return m_Class;
}
In this case, you'll not be able to corrupt your class, because you'll only be able to call const methods.
It's not the fall that kills you: it's the sudden stop - Down by Law, Jim Jamursch (1986)
|
|
|
|
|
When you have a CListCtrl and it is set to Large icons, every item that is added appears next to the last item (if there's room) or at the next line. I am making a class derived from CListCtrl but i want the items to be centerred in the Control, and every item that is added shoulder appear underneath the last one (so there arent any items next to eachother in any way).
Is there a preset flag for this or would i have to write my own code for this? And how would i start if i would? If anyone has some good sites about the ListControl and how to modify it they would be very appreciated 
Thanks
Kuniva
--------------------------------------------
|
|
|
|
|
Can someone help me with this? I need a simple and basic example to implement GL in a MDI app! Thank you!!
|
|
|
|
|
 Hi!
I was wondering if you can override the default functionality for OnFileNew and OnFileOpen to have your document's view open in only one child window as it happens in an SDI application.
More clarification:
When we create an MDI application we get a child frame window which gets the view inside it. If we have to say FIle New then I would like to replace the existing view in the same child window with the new one. Yeah an interesting quesion is why am i going into all the troubles of MDI when this is the functionality of an SDI application, but actually I have another document template also within this application. Can somebody help me out with this.
thanks
rahul
|
|
|
|
|
I am sure I have seen articles on this either here or on CodeGuru. Have you had a good look around the Doc/View articles?
It really shouldn't be difficult. You can overide OnFileNew etc. and do whatever you want with docs and views.
Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program
|
|
|
|
|
Hello, my problem:
Need a dialog box to get 2 coordinates (x,y) to draw a rectangle in the viewport!! I have managed to do it but only when I rezise the window!
Probably a stupid question but...
Thankx!!!
|
|
|
|
|
Call Invalidate().
Kuphryn
|
|
|
|
|
Call for View 1) Invalidate() 2) UpdateWindow()
===========================
My home is www.brigsoft.com
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
