|
Hello,
I am working on an mfc chat application in which i want to incorporate chatting in multiple languages.
I am able to type arabic and chinese and other languages in the text box but it is not able to dislay it in CRichEditCtrl.
Please tell me whats the reason.
Thanks In Advance.
|
|
|
|
|
Try getting the raw text from the richedit control - and look through to see what font it being used. I'd suspect that the rich edit control is using a font that can't display your characters...
Have a look at http://www.codeproject.com/KB/edit/rulerricheditctrl.aspx[^], a good article using the rich edit control, and try typing using different fonts - it may help with your problem.
Iain.
|
|
|
|
|
Dear All,
I have a problem to convert a byte array to a image in vc++.
Is it possible in vc++ to convert a byte array in to a image.
Please help to solve this problem.
|
|
|
|
|
What data structure are you using for image?
-Saurabh
|
|
|
|
|
|
http://en.wikipedia.org/wiki/Portable_Network_Graphics[^]
The above page gives quite a good explanation of the format. I'm assuming each byte in your array represents one pixel? You'll also need a palette (what colour is 0x17 ? ), and know the width and height of your picture.
Try just writing a simple 16x16 png to start with, then grow it.
Modification: PNG is a compressed format, but you could just do a rubbish job of that compression...
Good luck!
Iain.
|
|
|
|
|
Hi,
I want to make radio control transparent i tried with OnCtlColor it is working but when i put my control over a picture control with bitmap it is getting black,I am working VS2008 with MFC feature Pack.
Thanks in advance for any idea.
modified on Friday, November 14, 2008 4:41 AM
|
|
|
|
|
Maybe your parent window has the WS_CLIPCHILDREN style set? How do you mean you put your control over a bitmap? I supose you blit a bitmap onto the client area of the parent window in OnPaint or maybe OnEraseBkgnd.
|
|
|
|
|
Thanks for Reply.
WS_CLIPCHILDREN is false in my application and i working with formview.
first i am making control tranparent in OnCtlColor then i am moving it on the bitmap, it is working in VC6 but problem with VS2008 .
|
|
|
|
|
Maybe try giving WS_TRANSPARENT to your control. Am not sure if that would work or not.
|
|
|
|
|
Hello All
i am working in Win32 VC++ using VS 6.0
My window works fine and is Minimized in TaskBar....
if i click the mouse on Desktop (i.e not on my window).....is there any way so that my window come to know that the mouse has clicked down......i.e in short i want to send the mouse events to my window from anywhere.
Thankx In Advance
regards
aabid
|
|
|
|
|
|
Hi all,
In my mfc application I have a main window which has no title bar, no resizing frame, no border n all. I am programmatically creating title bar and maximize and minimize buttons.
For resizing and move operations I am handling hit test messages.
But since I have no title bar so system menu doesn’t appear by default, and also left click on task bar doesn’t maximize the window.
For this to work I added WS_MINIMIZEBOX | WS_MAXIMIZEBOX | WS_SYSMENU styles to my frame window. Everthing started working sysmenu on right click,maximize,minimize,move n all but unexpectedly resizeing stopped working. If I remove WS_SYSMENU resize starts working. I have no idea what happened. One solution thought was to add WS_THICKFRAME to the window but I don’t want to use it as it changes the look of window which client doesn’t want.
Can you suggest something on this?
|
|
|
|
|
You say you draw your own titlebar, why don't you draw your own minimize and maximize buttons too?
|
|
|
|
|
Hello,
I m using Microsoft Visual Studio 6.0 editor.
When I build my application and when I Execute (ctrl + F5) my application
then again a build dialog box is get displayed (which is displayed during Build (F7)
the application) & it ask me for build the application (having option Yes, No, Cancel).
I 'Clean' the application & then Rebuild it, then also
this problem continues. Also I delete the 'Debug' folder from the current directory
& then Rebuild application then also that problem is not solved.
Plz give me solution.
Thanks in advance.
Regards
Nikesh.
|
|
|
|
|
Is the date and time set correctly on your machine? Is it rebuilding the entire project, or just a subset of files? If the latter, are they the same files each time?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
Date and time set correctly on my machine. It rebuilding just a subset of files. And same files ask for
build each time.
Regards
Nikesh
|
|
|
|
|
Are you making any changes to the code such that a rebuild is indeed justified?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
I write VST plugins. These plugins use a lot of custom controls, e.g. knobs, sliders, etc. I've rolled my own library for these controls using Win32 and GDI+ mainly because it's hard to get VST to play nicely with MFC (long story).
What I do is use a resource editor and drag and drop the user control type onto the dialog surface. This makes it convenient to place controls in the correct position rather than trying to do it manually in code.
Anyway, I have a commercial plugin called Cobalt. It's been out since last January. Since then I've gotten a few rare bug reports that custom controls are not in the correct position. It's as if the scale the controls is using is larger than the underlying dialog they belong to.
Here is a screen shot of what I mean:
Messed up GUI[^]
Here is a screen shot of what it's suppose to look like:
Normal GUI[^]
The GUI comes in two sizes: Small and Large. I can flip between the two sizes in code with preprocessor directives so that it's easy to compile the resulting dll so that it uses one of the two sizes. My first thought when I came across this bug is that the code for the smaller size was using the coordinates for the larger size. But apparently both sizes suffer from the same bug on systems where this is a problem. And this doesn't explain why on the majority of systems the GUI looks correct. So I don't think it's related.
My biggest problem is that I can't reproduce the bug. So it's almost completely guess work. Could the units the code is using to place the controls be different somehow than what the system is using? I'm not even sure that question makes sense. I'm having a hard time figuring out what the issue is here (obviously). Thanks for any help.
EDIT: I think it's related to fonts somehow. The font type/size of the dialog box the controls belong to scales the overall position of the controls... I'm not to a point of having a coherent thought on this quite yet, lol, but I think I've found the trail.
EDIT2: (kinda going back and forth between two forums where I've posted this question):
My resource file specifies the font type. It seems as though on some systems the font type is bypassed... or something. If I delete the FONT line from the resource file, I can recreate the bug. Without the FONT specification in the resource file, Windows assumes (I think) a different type of font than what I used to create the resource file with, thus the positions of all of the controls are thrown off.
modified on Friday, November 14, 2008 2:18 AM
|
|
|
|
|
Could this be related to the DPI setting in windows? The user can set the DPI for the screen (so he gets bigger or smaller fonts, RightClick desktop, properties, dispay, advanced, Screen DPI). We had issues with this too since the dialog units the resource editor works with depend on the font setting, as you said in your post. Maythe the users who experienced that bug had a different than default DPI setting on their desktops.
|
|
|
|
|
Anthony S. wrote: Could this be related to the DPI setting in windows? The user can set the DPI for the screen (so he gets bigger or smaller fonts, RightClick desktop, properties, dispay, advanced, Screen DPI). We had issues with this too since the dialog units the resource editor works with depend on the font setting, as you said in your post. Maythe the users who experienced that bug had a different than default DPI setting on their desktops.
Yup. You're right. By changing the DPI on my system, I was able to recreate the bug.
What was your solution for this? Or is there one?
My stopgap approach is to use MoveWindow() to manually set the control positions on the dialog box. While this works, it's very tedious.
|
|
|
|
|
Well, i think your problem is that while your controls get positioned and sized according to the font setting, your background images don't. What i did was to stretch the background bitmap to make it bigger or smaller as needed (mostly based on the containing window size, since this gets bigger or smaller too). This can make the interface a bit blurry because of the stretching (also stretch-blitting is a slow process) but for one, it's still better than it getting scrembled and two, if the user doesn't want to (or cannot) use the default DPI setting, he should accept that this will make the interface look a bit less crisp. Something for something...
Btw we are not the only one who didn't originally think of this case, when you have a different DPI setting and you log out of windows it displays the "Saving your settings window", and the header of this window doesn't fill fully the area it was given...looks a bit lame... 
p.s: i changed my displayed name in the meantime (Anthony S. -> Code-o-mat), don't get confused, it's still me.
|
|
|
|
|
Please help!
My program is working alright in XP, but the editbox of it is non-working in Vista! Why???
|
|
|
|
|
LaHaHa wrote: Why???
Without providing any more information, it could be most anything. Does it happen with all edit controls, or just a specific one? Does it happen with a new project having default options, or just a specific one that you've been working on?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
Many thanks
I had solved it, the parameter of brush is wrong.
But it works in XP and doesn't work in XP!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
