|
Read it from the user's preferences. Call GetLocaleInfo() with LOCALE_IFIRSTDAYOFWEEK
|
|
|
|
|
Description of the Dialog
-------------------------
the Dialog contains a static image that stretches the entire Dialog window.
Ontop of the static image a CEdit box is located. (Auto VScroll = true, Vertical Scroll = true, Multiline = true, Readonly = true, visible = true)
What the code does
------------------
when the user presses a button, the hex code of the key is shown in the edit box on a new line.
Also, the image behind the edit box updates (gets DC, does a BitBlt of entire image, and finishes with SetBitmap).
The BitBlt() draws over the edit box, hence, I have to call CEdit::RedrawWindow.
Expected Results after the RedrawWindow method is called
--------------------------------------------------------
I was expecting the background image to be underneath the edit box, with the edit box containing the text and if necessary, a scrollbar to show so that I can scroll up and down in the edit box.
Actual Results after the RedrawWindow method is called
--------------------------------------------------------
The background image is indeed behind the edit box, however, when the vertical scrollbar needs to show it is not seen after RedrawWindow() is called. Basically, the vertical scrollbar part of the edit box doesn't redraw - it is still there (I can guess where it is and click it and scroll up and down).
I've tried ShowScrollBar(TRUE) followed with RedrawWindow(), but this doesn't redraw the scrollbar either.
Is there anything I can do to force it to redraw the entire edit box ?
|
|
|
|
|
abiemann wrote: gets DC, does a BitBlt of entire image, and finishes with SetBitmap
What i understand is that, you does the image operation in a memory DC. And then gets the bitmap from that memory dc and set to the static right?
abiemann wrote: Expected Results after the RedrawWindow method is called
Which all flags did you specify in the Redraw window? Can you show that code?
|
|
|
|
|
Nave, thanks for pointing out the flags.... I experimented and the following worked:
m_editKeypresses.RedrawWindow(NULL, NULL, RDW_FRAME + RDW_INVALIDATE);
The flags "RDW_FRAME + RDW_INVALIDATE" must be specified
|
|
|
|
|
abiemann wrote: RDW_FRAME + RDW_INVALIDATE
that flag are not meant to add but you should or them like
m_editKeypresses.RedrawWindow(NULL, NULL, RDW_FRAME|RDW_INVALIDATE);
|
|
|
|
|
Hello,
I have a problem reading data from a INI file using GetPrivateProfileString method, only on Windows Vista.
When I read from a CFG file no problem, but GetPrivateProfileString always return the default value reading a INI file located on Windows directory (C:\Windows).
Anybody knows this problem?
Thanks,
Cris.
|
|
|
|
|
Cris wrote: Anybody knows this problem?
Probably related to Vista's UAC.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Thats right... I have fixed my problem reseting the UAC configuration.
But, why the UAC configuration cause this problem?
[]'s
Cris.
|
|
|
|
|
Cris wrote: But, why the UAC configuration cause this problem?
Because you were trying to access an object in the c:\windows folder. Most everything in Vista has been locked down.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
DavidCrow wrote: Because you were trying to access an object in the c:\windows folder.
bingo... you beat me to it.
I am trying to be good an hang out here more often. 
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
Why would UAC interfere with a call to read an INI file?
|
|
|
|
|
Michael Dunn wrote: with a call to read an INI file?
you are outside of your "accessable" directories. Even in XP you can restrict access to windows, or program files. theoretically you should only have read or write access to your program's director and sub-directories. even if you were to try ../common/config.ini if you have security set to full it will refuse you read access. We had to get an exception for our software for a few years until I got everything moved to the install folder... bad habits die hard...
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
That still doesn't explain why would UAC interfere with a call to read an INI file. Restricting access to \windows makes no sense - how would you use the computer if you couldn't access \windows?
|
|
|
|
|
Michael Dunn wrote: That still doesn't explain why would UAC interfere with a call to read an INI file. Restricting access to \windows makes no sense - how would you use the computer if you couldn't access \windows?
No one is supposed to have direct access to windows, windows does, but not the programs. We've just been too accustomed to lower security.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
Hello,
I have a application that use the OnPrint() MFC class. This application work allready 2 years without problem.
Now I see the preview and it's look good , but when printing I geet a blank page. The printer is the same and also the driver.
Do have any one a idee? What cann I check to fix my problem.
Thank you to help me.
AutreChien
|
|
|
|
|
NorGUI wrote: What cann I check to fix my problem.
The printers toner cartridge.
|
|
|
|
|
We used to have a problem like that when users would have the option to change background and foreground colors in the app. They would make the background black and the foreground white, but the app would force a white background during printing but leave the foreground white.
They didn't have print preview however, so I'm not sure if this could be related but I thought I'd post it as an idea.
|
|
|
|
|
I am currently involved a project that requires that I have random access to multiple files on disk. I have a single 'file writer' object that handles writes, but I am unsure about how to proceed with reads.
The question is: If I want to be able to service multiple 'reads' at the same time to a single file should I have a single object (an fstream) that is synchronized (using a lock) or multiple fstream objects that are independent. I want to take advantage of my raid hardware as well as multiple processors throughout the application. My initial thought is that having multiple 'reader' objects leaves synchronization up to the OS, and that using some type of locking mechanism (such as a criticalsection/mutex) could slow performance.
Any help here is much appreciated.
On a side note: If I'm just writing buffers of data (or 1 byte aligned structures) does it make more sense to just use stdio functions?
|
|
|
|
|
KenThompson wrote: My initial thought is that having multiple 'reader' objects leaves synchronization up to the OS
What OS and where is it documented that it performs such synchronization. And by this I assume you mean synchronization to the "write operations".
KenThompson wrote: and that using some type of locking mechanism (such as a criticalsection/mutex) could slow performance.
"would" slow performance, it's not in question. However without the OS performing synchronization, of which I am unaware, you would have to do it to avoid reading corrupted data. You could optimize by creating a far more complex mechanism like Databases do of managing what "parts" of the file are locked for writing. Which of course raises the question of why you wouldn't just just use a database because they already implement everything you require.
Also you are not clear if this is across threads or across processes. The later synchronization is far more expensive.
|
|
|
|
|
I'm already synchronizing write and read operations. By this I mean that I keep track of what is currently being done to the file. Basically, the writer never goes backwards, so whatever has been written is fair game in regards to reading. The only random access is reading. A database for this application isn't acceptable.
The question remains though. What approach is the best? Have a single reader per file handling many requests. (ie. setg to the offset) or having several fstream objects created that read independently, in a shared mode.
I didn't mean that the OS, in this case Windows, prevents corruption when modifying files. I should of been more clear in my statement. I meant to say: My initial thought is that having multiple 'reader' objects is perfectly acceptable and not a performance hit. In addition, in a raid situation would it not make more sense to create multiple file streams to the same file due to the very nature of multiple disk heads? I'm not all that aware of where there is any performance to gain based on implementation. I can only assume that if I issue two reads to the same file, via two streams, that the raid controller (in my case raid 5) would out perform a setg operation. Maybe not with 2 reads, but maybe 100s of reads per second. Does this make sense?
|
|
|
|
|
KenThompson wrote: Does this make sense?
Absolutely. It would seem, on the surface (not a valid assessment), that multiple readers would be much more efficient. You might consider just implementing that and then run a profiler and see if that area even stands out at all. Sometimes (usually) profiler results will surprise you. 
|
|
|
|
|
Thanks, I needed some sanity here. What type of profiler do you use? I've been playing with a few intel products, but the cost sours me to them.
|
|
|
|
|
QC mostly runs them (several). I think the last time I used one myself it was an Intel product. The company has lots of money so cost is not an issue.
|
|
|
|
|
KenThompson wrote: A database for this application isn't acceptable.
So its better to write half of a database on your own instead of using e.g. SQLlite[^]?
KenThompson wrote: Does this make sense?
I think no. You would only ever work on buffers managed by the OS. The Harddisk-Heads would ascend and decend its cylinders all the time, doing the read/write out of order.
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words
|
|
|
|
|
SQLite is designed for use with databases sized in kilobytes or megabytes not gigabytes. Therefore, it is unacceptable.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
