|
Are you using 9X? If so, you may want to skip the CEdit entirely - it is limited to 64K of data.
I'd use a custom control, although this is no trivial amount of work. Are there any articles here on CodeProject about this kind of thing?
You can pick your friends, and you can pick your nose, but you can't pick your friend's nose.
|
|
|
|
|
A viewer is easy, editing the file is more awkward.
Simply create a SDI prog with a CScrollView style and the create what was called a virtual view onto the file. The easy way if to create a DWORD array in which you store the position of the start of each line, e.g. read the file and for each line store the start position of each line, makes finding each line easier, when scrolling backwards. Or the old fashioned way write this data to a temporary binary file, which is then used as an index. Remember to display the 1st screen full very quickly
Then when reading the file store "100" lines, i.e. a bit more than a screen full into a CStringArray. You now have the data to display.
This is a bit of a kludge but it solves the problem of stepping backwards through an ASCII file.
There is a cavaet beware of the bug that the max value in a scroll control is 32767, so if you file is > 32767 you need to find the M$ workaround.
I have ued this method for a specialised file viewer and it works very well.
If I have seen further it is by standing on the shoulders of Giants. - Isaac Newton 1676
|
|
|
|
|
A good way to access files that are very large is to use memory mapped files. PJ Naughter has a good class wrapper to handle implementing them. Essentially, the file is mapped into memory and you access it (forwards or backwards) with pointers as if everything were in an array. The operating system handles all of the buffering of data for you.
You can take any section of the file and do with it what you want in any sort of control, and it works for both read-only and writeable files. I have used memory mapped files that are on the order of 600+ MB without difficulty.
Dave
"You can say that again." -- Dept. of Redundancy Dept.
|
|
|
|
|
Yes I was going to suggest memory mapped files as well. MMF is an excellent way to handle various operations on large files, quickly and efficiently. You could probably just build a vector<int> which had the offset to the start of each line and use this in a virtual list control. Editing is a lot more work, but you said you don't need that.
Re. "writeable files" yes you can, but you can't efficiently insert or delete, just overwrite or append.
Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program
|
|
|
|
|
Hello,
I have a problem with these function.(i work with VC7 and MDI project)
when i do GetWindowRect to get Child window coordinates i get coordinates from the top left (0,0) of the screen,it's OK.
But when i want to position window i use SetWindowPos ans there is a probleme because SetWindowPos sets the window position from the top left corner of the client area of the main frame !!
You know how can i get function like "GetWindowPos" or "SetWindowRec" ??
Thx in advance
|
|
|
|
|
The functions you use are all ok. But you need to adapt the origin by calling ScreenToClient() from the window which holds the client window to adapt the coordinates.
So from within your client it should look like:
CRect rct;
GetWindowRect(&rct);
GetParent()->ScreenToClient(&rct);
SetWindowPos(...);
|
|
|
|
|
THX ! 
but with ScreenToClient() i get the height and width of the window (like GetClientRect), but not the position in the client area of the main frame.
ex :
with :
GetWindowRect(&WndRect)
i get :
{top=159 bottom=476 left=233 right=886}
after :
GetParent()->ScreenToClient(WndRect);
i get :
{top=<big>0</big> bottom=317 left=<big>0</big> right=653}
(the window is not in the top left corner of the client area )
you know how to have coordinate in the client area?
|
|
|
|
|
First of all it seems to me like you called GetWindowRect on you frame window instead of your child window, because your client coordinates should never return 0 in your case (a child window should not have it's upper-left edge at the same point as it's parent).
To move your window according to the client area, I think a call to GetClientRect should return the it's coordinates when called on a CMDIFrameWnd, thus giving you the coordinates of your client area in relation to the windows origin (0, 0). With these information you only need to add the obtained value to your new child's position and then move it to it's new place - that's all
|
|
|
|
|
i have already try GetClientRect but I have always (0,0). but i should call GetclientRect in specific place ?
thx you for your help !
|
|
|
|
|
I had a whole night to think about your problem ....
I thought a call to GetClientRect from within your mdi frame wnd would give you the coordinates of your client area ... but possibly is does not. So what I came across is that every mdi window holds a variable called m_hWndMDIClient, a handle to it's client area. Calling GetWindowRect on this handle, the converting it to the mdi frame's client coordingates with ScreenToClient should deliver you your requested information...
|
|
|
|
|
lol Sorry for your bad night !!
i'm going to try this...
I keep you informed
|
|
|
|
|
jeremysay wrote:
Sorry for your bad night !!
Doesn't matter ... I can make up for my missing sleep at work...
|
|
|
|
|
Schlaubi wrote:
Calling GetWindowRect on this handle
oups  i'm sorry but i don't know to call GetWindowRect on handle
can you give me sample code ?
|
|
|
|
|
Simply call the API version ::GetWindowRect(), where the first parameter is the handle to the window from which to detect the coordinates. A second approach could be Attaching the handle to a CWnd object and then calling it's GetWindowRect (but I prefer the former way )
|
|
|
|
|
GGRRRREEEAAAAATTTT it's works fine !! i found
CWnd* pMDIClientWnd = CWnd::FromHandle(pFrame->m_hWndMDIClient);
if (pMDIClientWnd)
{
pMDIClientWnd->GetWindowRect(&ClientRect);
}
to Use m_hWndMDIClient, it is the right solution !! i get the coordinates of client area and i can to position my window where i want !!
THX THX again Schlaubi you help me so much, i should send you bottle of wine
|
|
|
|
|
jeremysay wrote:
i should send you bottle of wine
Nice idea ... thx
btw: I prefer the red one, dry and fruity
|
|
|
|
|
jeremysay wrote:
GGRRRREEEAAAAATTTT it's works fine !! i found
...and calling
::GetWindowRect(m_hWndMDIClient, &ClientRect)
would do it without needing to deal with CWnd.
Sorry, but in my last post I forgot the code snippets .. but luckily you found the solution anyway.
|
|
|
|
|
Schlaubi wrote:
but luckily you found the solution anyway
you tell me in post to see m_hWndMDIClient and i search sample code in google and i found an example, i didn't find this alone
|
|
|
|
|
I dont see a setItemIndex() in CListCtrl members but lets say I want to make my item #5, now the item #2 (and the original item #2 can just get pushed down in the list). How does one do that? I see Inserttem but thats not what I'm doing. Item #5 already exists in the list....
Appreciate your help,
ns
|
|
|
|
|
Use GetItem(5) to retrieve the item information, then delete it and add it again by using InsertItem().
|
|
|
|
|
Some days ago I got this very helpful hint here in the boards:
"In VC++ 7.0, there's an option called delayed loading which loads DLLs the first time thery're used. If you have this compiler, this is surely the fastest way to get your problem solved."
Could anybody direct me to this option in VC++ 7? I just instaleld it.
Thanks so much!
-- narada
|
|
|
|
|
Project Settings->Configuration properties->Linker->Advanced->Delay Loaded DLLs
|
|
|
|
|
Thanks a lot!
It's so great to get this help!
-- narada
|
|
|
|
|
... or xml config file 
When declaring things like a MAX_FIELD_SIZE or MAX_(insert your thing here), do you use #define (which has no idea how the literal is being used in your code because it's a pre-processor directive [i think]) or do you use enums? Or do you keep all that stuff in the registry, or a config file?
Any thoughts/preferences/opinions?
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
Well, I try to use const.
#define anyways is not a good idea. Since, there is no type-checking.
XML config file also sounds like a good idea.
I hate messing with the registry 
Pankaj
Without struggle, there is no progress
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
