|
using VC++ 6.0 sp5, Windows XP pro. SP2
I need to give user the ability to edit column structure in CListCtrl.
Problem: when data exists in rows and the user inserts or deletes columns
The row/column data will get mixed up, data will be placed in wrong column.
Microsoft has published Bugs to this effect but it appears to be for older versions.
Is ClistCtrl not capable of dynamic column structuring ?
-- modified at 13:19 Thursday 22nd February, 2007
|
|
|
|
|
This is my first time posting to something like this so bare with me.
I am using Visual Studio 2005 and C# but i can integrate visual C++ code using a dll. I've looked everywhere and I can't seem to find a way to do what I want. The goal is to be able to access a GIF file's color table. I'm trying to reduce the number of colors in that image and the best way to do that I am assuming is by accessing the color table and taking the top X number of colors and applying that to the image. I have the applying part working, but the problem is getting those colors to begin with. Currently I am going through the entire image(which is required for my purposes to be 2400 px by 2400 px) and finding the color of other pixel on every other line. This takes a little time and isn't quite as accurate as I would like.
Thanks!
|
|
|
|
|
The easiest way I know of is to use GDI+.
If you load the GIF as a GDI+ Bitmap object then you can use:
1) GetPalette()/SetPalette() to read/write the color table
2) LockBits()/UnlockBits() to access the pixel data to change pixels to index the appropriate
entries in the new color table.
3) Save() to save the new image.
With C# you can use the .NET GDI+ wrapper classes (System.Drawing.Bitmap) I believe.
Then you don't have to use C++.
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
can i remove the ok,cancel&apply buttons provided by the framework when using property sheets and provide my own buttons.Please anyone help me.
-- modified at 14:25 Wednesday 21st February, 2007
|
|
|
|
|
Yes... I believe you can get the buttons using a function like GetDlgItem(...) from the property sheet (which is the parent window of the buttons and the pages), and you can then move them, hide them, resize them, or change their text.
You can create your own buttons on the property sheet as well, but if you only need one or two features, you should be able to just change the text on the existing buttons, and override their functionality.
If you have to create your own controls, you will need to manually add message handlers for their events.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
thanks for replying me.It is really helpfull for me.
|
|
|
|
|
Is there any simple way how to get desktop rect - but without taskbar?
Thank you
viliam
|
|
|
|
|
Check out SystemParametersInfo(SPI_GETWORKAREA...)[^]
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
thank you,
that's I was looking for
viliam
|
|
|
|
|
i'm writing an app with the XLAutomation class included into it, the app builds fine, but when i run it sometimes it seems i can't access Excel (read/write) and then i get this error message:
From the XLAut.. class: "ReleaseVariant: unknown type" and "ReleaseVariant: Array contains non-variant type"
and when i debug the error further:
"Unhandled exception in "MyApp" (OLEAUT32.DLL): 0xC0000005: Access Violation"
And it wont go away even if i close the app and restart it, seems theres something in the memory.
somebody know what this means? any solutions?
thanks
|
|
|
|
|
More information would be helpful. Can you show a call stack when the exception is generated and the source code around the line in that triggered it?
Steve
|
|
|
|
|
What I want to do.[^]
(Server seems a bit flaky, hit reload if it fails)
From the image, you can see I've already figured out that I want to remove WS_EX_CLIENTEDGE from the frame window. Problem is that I can remove it in PreCreateWindow(), but something still draws it anyway. Been looking around (Google searches) and it seems there is some problem when trying to remove WS_EX_CLIENTEDGE from a CFrameWnd used as a splitter view but no one's bothered to post whatever solution they figured out.
|
|
|
|
|
Try removing the border flags in a WM_CREATE handler (OnCreate()) for the frame window.
I haven't looked through the source but maybe the splitter sets the style later (seems unlikely
but you never know, well unless you look at the source  ).
Also can you sow your PreCreateWindow code? Are you sure you are removing all the appropriate
styles correctly?
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
BOOL CTabFrame::PreCreateWindow(CREATESTRUCT& cs)
{
BOOL x;
x = CFrameWnd::PreCreateWindow(cs);
cs.dwExStyle &= ~WS_EX_CLIENTEDGE;
return x;
}
I verified that this removes the style by using Spy++/Winspector. Yet the border still shows up. It seems to draw it regardless of the style setting. Can't try the OnCreate() thing right now. Got to go to a meeting.
|
|
|
|
|
Thanks. I use this for all my splitter panes and it's ok. You may use other styles in your frame
windows but in my case there's client windows within all of them so I strip all styles except
the two shown.
BOOL CMySplitterPane::PreCreateWindow(CREATESTRUCT& cs)
{
CFrameWnd::PreCreateWindow(cs);
cs.style = WS_CHILD | WS_VISIBLE;
cs.dwExStyle = 0;
return TRUE;
}
Also, make sure any client windowss of frames have their border styles removed as well
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Just tried that. Still doesn't remove it.
Not sure what you are referring to by client windows. I'm not all that familiar with MFC doc/view architecture stuff (I kinda wing it, if you know what I mean).
|
|
|
|
|
dontknowitall wrote: Not sure what you are referring to by client windows.
"Client window" is old-school I guess...I came from Borland's OWL framework originally.
Although, I just checked the MFC docs and they still call them clients 
I'm referring to the child window imbedded in a CFrameWnd window - generally created in a
CFrameWnd::OnCreateClient() override. CFrameWnd contains the "decorations" - toolbar(s), menu,
status bar, etc. - and automagically keeps a "client window" positioned within these
"decorations".
Anyway, the fat ugly border is from the splitter. Not only is the splitter bar drawn but (I
assume) to make the bar blend to the sides, the sides are drawn too. Since the splitter is drawn
"raised" there's no way to get rid of it without drawing your own splitter window.
Here's a screenshot[^] from one of my apps. It's the best I've been able to do with the borders
using tab control and splitter window without drawing anything myself. Anything there defferent
from your results?
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Looking at your pic it looks like your second toolbar (the bottom one immediately above the tab control) is acting as a parent window, not a sibling window as it should be. Notice how it's right hand side border extends down to and around the bottom of your view, while on the left hand side there is no border present at all.
Look into that as I am going to assume that is where your problem lies, not in the frame window itself.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
What are you talking about? The hierarchy goes:
MainFrame w/ Standard toolbar
|- Vertical splitter
|- Tree view
|- Horizontal splitter
|- CFrameWnd w/ Standard toolbar
|- CTabCtrl wrapped up in a view.
|- CScintillaView
|- IWebBrowser2 view
|- CFrameWnd w/ Standard toolbar
|- CReportCtrl (a CP project)
Using ST_SplitterWnd here on CP for splitters.
There's nothing hokey with the toolbars AFAIK - CFrameWnd is managing the toolbar. And the image is a mockup I put together using Photoshop. However, I know it is possible to remove the style because I removed it with Winspector (but the effect was only temporary - resizing the window/moving the splitter restored it even though the style was still gone).
|
|
|
|
|
You're not using the MFC splitters? 
The splitter changes the style of the window back to clientedge? Can you remove that from the
splitter code?
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Well, ST_SplitterWnd (here on CP) seems to wrap up MFC splitters in a "nicer" way (it IS derived from CSplitterWnd). I dunno - it works pretty well for various three-pane apps I've done. Just a couple function calls and - voila - new splitter with view. However, for this one view, I want to drop the border (client edge) that gets drawn.
Where does it change the style in ST_SplitterWnd? Only place I've found WS_EX_CLIENTEDGE is in PreCreateWindow() and I've already done the necessary changes to that function. Spy++ and Winspector confirm that the client edge is gone...yet it is drawn anyway.
Here's how the CFrameWnd gets created:
ST_SplitterWnd::Create() calls CSplitterWnd::CreateView().
CSplitterWnd::CreateView() dynamically creates the view and then calls Create().
Create() calls PreCreateWindow() which calls my derived PreCreateWindow().
My PreCreateWindow() calls CFrameWnd::PreCreateWindow(), which alters the extended style to include WS_EX_CLIENTEDGE.
My PreCreateWindow() alters the style as Mark suggested.
The ST_SplitterWnd class doesn't alter WS_EX_CLIENTEDGE.
|
|
|
|
|
Cool. So what are you seeing at this point? Any change from your original screenshot?
You should only see the splitter window border. Are you seeing anything ugglier on the boders
than in these screenshots?
Screenshot 1[^]
Screenshot 2[^]
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
No change from the original screenshot (actually a mockup done in Photoshop of two separate screenshots - the one in the 'red rectangle' is what actually appears - the rest is a screenshot where I used Winspector to remove the WS_EX_CLIENTEDGE style - it changed instantly when CFrameWnd had the style [i.e. before I started fiddling with PreCreateWindow()]).
I can't tell what the difference is because you've got themes enabled - it is a lot easier to tell what is going on if themes are disabled. However, I do notice one thing different: My toolbar has a line below it while yours doesn't. That line is there because the tab control (view) has the WS_EX_CLIENTEDGE style. I want it that way because it looks better. However, it creates the "double-border" thing because the splitter or frame window is drawing another "client edge".
|
|
|
|
|
dontknowitall wrote: That line is there because the tab control (view) has the WS_EX_CLIENTEDGE style. I want it that way because it looks better.
Yeah I've gone back and forth on that one. Still undecided!
dontknowitall wrote: However, it creates the "double-border" thing because the splitter or frame window is drawing another "client edge".
Exactly! I've been looking at the CSplitterWnd code (that's always bugged me).
Eventually I'l have time to write my own splitter but custom UI is on the back burner for me
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
Mark Salsbery wrote: Yeah I've gone back and forth on that one. Still undecided!
Me artist. Me like pretty. Me say it look better, it be better.
Ook. Ook.
Mark Salsbery wrote: Eventually I'l have time to write my own splitter but custom UI is on the back burner for me
So...what you are saying is that I'd have to roll my own splitter? ST_SplitterWnd is probably a better codebase to start from and then just override the painting code from CSplitterWnd in ST_SplitterWnd but that would really only be necessary for the case where someone wants to set an alternate style. The default works pretty well for most cases.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
