|
|
Hi All,
Does anyone have any advise about the best way to go about displaying line numbers in a CRichEditView that display correctly while scrolling? Looking for the effect in many IDEs, and editors like Homesite. Thanks for any suggestions.
Rick Gavin
|
|
|
|
|
|
I've inherited my control from CListCtrl and overriden OnCustomDraw.
And in OnCustomDraw method i do my own drawing only at CDDS_ITEMPOSTPAINT|CDDS_SUBITEM stage. At other stages before this one CDRF_SKIPDEFAULT flag is UNset (i want standart CListCtrl to draw header).
Now, with every drawing of my control it flickers.
I tried to use double buffering (draw in memory DC and than BitBlt to original), but there was just black screen.
Does anyone know what's the problem? And how can i avoid flickering?
Thanks in advance.
|
|
|
|
|
With CDDS_POSTPAINT you're getting the chance to draw *after* item/subitem was painted. What kind of information are you displaying?
Tomasz Sowinski -- http://www.shooltz.com
"Yields falsehood when preceded by its quotation" yields falsehood when preceded by its quotation.
|
|
|
|
|
I'm drawing images and text.
the problem, why i cant use standart list, is that i have to draw multiple selection in my own way.
e.g. selected images should be drawn like another image etc.
its not my idea, so did customer want
nobody is perfect
|
|
|
|
|
You've mentioned that CDRF_SKIPDEFAULT is unset, so basically you're telling Windows to draw the default stuff and notify you when it's done.
Except this 'selected image', what are other things you want to do with selection?
Tomasz Sowinski -- http://www.shooltz.com
"Yields falsehood when preceded by its quotation" yields falsehood when preceded by its quotation.
|
|
|
|
|
damn
now i'm sure - i'm stupid
the problem wasnt in custom draw and not in listview at all
but thank you for giving me a reason to think
nobody is perfect
|
|
|
|
|
Hello,
when I move my mousepointer of a MSFlexgrid is there any way to find out, which cell/row is pointed? I need this, because I wan't to display further information about cell-data.
|
|
|
|
|
I've been taking my project back and forth between my home and work machines (win2K and XP) and each time a perfectly working version on one will crash on the other until I do a rebuild all. Then it works fine! I suddenly realized (and am aghast ) that this means I have to rebuild on the users machine - Impossible. SO what are my options? WOuld it work on all XPs if I distributed a version built on XP, and on all WIn2K if I distributed a version built on Win2K? Does this happen to you. Why does it happen and how to you get around this? I dont touch the code at all on either machine. Just a Rebuild All and the program works perectly. Incidentally its both the release and debug versions that I have to rebuild.
Thanks,
ns
|
|
|
|
|
Rebuild All doesn't compare the modification dates of source/obj/exe files. Normal build minimizes the work and doesn't compile source files when corresponding obj is already present and has later date.
Maybe date/time clocks on your machines aren't in sync?
Tomasz Sowinski -- http://www.shooltz.com
"Yields falsehood when preceded by its quotation" yields falsehood when preceded by its quotation.
|
|
|
|
|
Nope, the clocks are synced except for perhaps a few minutes difference.
|
|
|
|
|
But you're moving source between computers, not .exe?
Tomasz Sowinski -- http://www.shooltz.com
"Yields falsehood when preceded by its quotation" yields falsehood when preceded by its quotation.
|
|
|
|
|
This is true. I've only been testing the perfectly working version from the debugger. I'll try to run the exe from the release and debug folder. Maybe that will not crash. What is the reason that the source needs rebuilt?
Thanks,
ns.
Do you feel certain that the exe from the debug/release folder wont crash? I cant check it out till tonight (the machines at home).
|
|
|
|
|
ns wrote:
What is the reason that the source needs rebuilt?
I'd say that there's 90% chance the problem isn't related to rebuild. But still, there's 10% left
Can you compare the release binaries produced on both machines?
Tomasz Sowinski -- http://www.shooltz.com
"Yields falsehood when preceded by its quotation" yields falsehood when preceded by its quotation.
|
|
|
|
|
I will next time it happens. First I have to go figure out how one compares release binaries! THe only thing I know is WinDiff and I've used it only for text files. So if the binaries are different then its a clue indicating what? Sorry to keep bothering you with my questions.
Appreciate your help,
ns
|
|
|
|
|
ns wrote:
THe only thing I know is WinDiff
fc /b from the command line.
Binaries should be (almost) identical. I believe there's some date/time stamp in the PE file. Other differences may indicate different versions of DLLs you're linking with at runtime.
BTW: if debug build crashes, you should easily pinpoint the problem.
Another thing: are you using #import?
Tomasz Sowinski -- http://www.shooltz.com
"Yields falsehood when preceded by its quotation" yields falsehood when preceded by its quotation.
|
|
|
|
|
Tomasz Sowinski wrote:
Binaries should be (almost) identical. I believe there's some date/time stamp in the PE file.
It's semi-documented how to avoid this (sort of). Look up the environment variable LINK_REPRO in MSDN. When set it makes the linker set the PE timestamp to 2^32-1 (i.e. 0xffffffff).
|
|
|
|
|
Cool! How did you find this variable? Late night debugging session?
Tomasz Sowinski -- http://www.shooltz.com
"Yields falsehood when preceded by its quotation" yields falsehood when preceded by its quotation.
|
|
|
|
|
I certainly am using #import. Is this known to cause a problem like this?
Thanks for the binary comparing info.
ns
|
|
|
|
|
Instead of a debug exe build a release exe and take it home and run it. If it works then you are OK. If it does not, then you need to worry about the DLLs your exe is using and various dependency and version issues. It should not happen but yo never know.
|
|
|
|
|
Does it also crash if you start the exe or just when started from the IDE ?
It could be differences in the MFC dll's or something like that(?). If so you could use static linking so the exe would run on any version.
Check for compiler warnings.
Good luck
Rutger
|
|
|
|
|
Isnt it a fact that you can only choose static or dynamic linking at the very start of the program? Can you switch at this stage (midway), How do you do that? I saw such an option when I created the app using the appwizard.
Thanks so much,
ns
|
|
|
|
|
ns wrote:
snt it a fact that you can only choose static or dynamic linking at the very start of the program? Can you switch at this stage (midway), How do you do that? I saw such an option when I created the app using the appwizard.
Thanks so much,
You can change it if you go to Project->settings (or press <ALT>+F7) then you will see the general tab where you can select how to use the MFC (options are not at all, shared or static)
Regards
Rutger
|
|
|
|
|
It happened to me too and I finally found the reason: if one of your machines has "Microsoft .NET platform" installed and the other doesn't, the problem arises. Then I completely removed .NET from my machine and the problem is gone.
I'm not sure if this solves your problem but that's how I solved mine.
|
|
|
|