|
Generally, with string we mean a sequence (i.e. one or more) of characters.
In C language, char is a data type (corrensponding to a 8-bit signed integer , i.e. ranging from -128 to 127 , while an unsigned char is a 8-bit unsigned integer , i.e. ranging from 0 to 255 ), a string is, by convention, a sequence of char s zero terminated, for instance:
char c1 = 'A';
char c2 = 13;
char c3 = -20;
unsigned char uc1 = 10;
unsigned char uc2 = 'A';
unsigned char uc3 = 250;
char s1[]= { 'H', 'e', 'l', 'l', 'o', '\0'};
char s2[]= "Hello";
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
There is a lot of samples for RGN's for bitmaps but I need to create a RGN for Text with a font and size.
How can I do it?
thanks in advance
|
|
|
|
|
Can you more explain,please?
Of one Essence is the human race
thus has Creation put the base
One Limb impacted is sufficient
For all Others to feel the Mace
(Saadi )
|
|
|
|
|
I want to display text on the screen in such a way so the user will see only the text (Not the window).
The RGN is made to disable coloring outside of specific places in the window.
The effect of it is so you can make windows in a shape you design as so
http://www.codeproject.com/KB/GDI/coolrgn.aspx[^].
How do I do the same effect on text?
|
|
|
|
|
Do you mean you wish to create a region with the shape of text? If so, try this, am not sure if it works but it is worth a try:
1. Create your font and select into a DC (a memory DC should work)
2. Use BeginPath to begin defining a path
3. Use TextOut or DrawText or such to display the text
4. Use CreateFromPath[^] to create a region.
It is possible that it only works with vector-based fonts.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
|
|
|
|
|
Thanks for helping
The function don't work with all fonts so I did this
SetRgn(CString str)
{
CRect r;GetClientRect(&r);
CMemoryDC dc(GetDC(),r);
CFont font;font.CreatePointFont(120,L"Arial",0,true);
COLORREF bgColor=dc.GetBkColor();
dc.FillSolidRect(r,bgColor);
dc.SelectFont(font);
dc.TextOut(0,0,str);
CRgn rgn,tRgn;rgn.CreateRectRgn(0,0,0,0);
for (int x=r.left;x<r.right;x++)>
{
for (int y=r.top;y<r.bottom;y++)>
{
if(!(!tRgn))tRgn.DeleteObject();
COLORREF c=dc.GetPixel(x,y);
if(c!=bgColor)
{
tRgn.CreateRectRgn(x,y,x+1,y+1);
rgn.CombineRgn(rgn,tRgn,RGN_OR);
}
}
}
SetWindowRgn(rgn);
}
|
|
|
|
|
I supose it really only works for vector-fonts since a raster-font probably has nothing to put into a path...Anyways, isn't that solution a bit slow?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
|
|
|
|
|
I did a test in debug mode with breakpoints...(not the best way to check)
1000*1000=1,000,000 loop
It was only 5 sec.
a normal textout will not export so much as so.
Update...
CSize sizeText;dc.GetTextExtent(str,str.GetLength(),&sizeText);
for (int x=r.left;x<sizetext.cx;x++)>
{
for (int y=r.top;y<sizetext.cy;y++)>
....
modified on Monday, December 29, 2008 9:34 AM
|
|
|
|
|
On some files fclose is taking long time to close the file.Can someone please tell that in which condtion it can take time to close and how it is internaly implemented?
Thanks in advacnce.
Regards,
Vishal
|
|
|
|
|
Try calling flush() to flush all writes to the file before calling fclose().
This may reveal that the cause of the slowness is the buffered writes.
|
|
|
|
|
Thanks Richard.
I have tried fflush before fclose.fflush returns immidately but fclose is taking time.time for closing the files get increased with increase in file size. with 100MB it is 30 sec.With 200MB,it is 1 min and 300MB it is 2min and so on.It is happening with one type of files(.dat files) only.I tried by closing some other file at same path with same code and this file is closed immidately.I have tried everything but I am not able to find the reason.Please give some other sugestion,I can try.
Thanks
Vishal
modified on Sunday, December 28, 2008 4:18 AM
|
|
|
|
|
Hi,
is there anything special about your file? e.g. is it on another PC, in a special folder, ...?
does it need some post-processing, like compression, encryption, ...?
|
|
|
|
|
Thanks Luc.
There is nothing special about this file.It is just *.dat file in which logging message are written.It is not in another PC and it is not in special folder.
To confirm this,I have also tried by putting some other file with same size on this folder and rename in to culprit file name but this file get closed immidately.
After completion of this file(on day change new file is created), it is processed by some other modules to create the reports.
Thanks,
vish
|
|
|
|
|
The source code comes with Visual Studio.
Why not step into the fclose() code with the debugger and see what's
happening?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Thanks Mark.
I tried to debug "fclose" on my m/c.It is not going inside of fclose.
I am not able to see its code also.I was assuming that only header files comes with visual studio.
If I can see its code then it would be great help.Could you please tell that at which location these
source files are?
Althogh this problem is not reproducible on my local m/c.It is happening on live system only.
Even then,I can see code and put some OutputDebug strings to see where it is taking time.
Please tell that how can I step in to fclose?
Thanks,
Vishal
|
|
|
|
|
What version of Visual Studio are you using?
I see fclose() implemented in the file C:\Program Files\Microsoft Visual Studio 9.0\VC\crt\src\fclose.c
on Visual Studio 2008.
I would guess the delay is happening when the buffered contents are flushed (i.e. actually written)
to disk. You can check by opening the file with the commit flag (c) and calling fflush()
(without that flag, fflush() returns immediately).
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Earlier I had doubt related to fflush or some other factor.To know this first I tried by calling fflush just before fclose.It does not make any difference.
Then in second test ,I tried by just open and close the file.Nothing in between these two.
even in this case it was taking time.
I wil try by giving "c" in file open mode.Now I opening the file by "a+",I will change it by "ca+".
Can I also put some logging message in fclose it and recompileit lirary?
Thanks,
Vishal
|
|
|
|
|
Vishal Kumar Soni wrote: first I tried by calling fflush just before fclose.It does not make any difference.
Correct. fflush() doesn't flush without the commit flag.
Vishal Kumar Soni wrote: Can I also put some logging message in fclose it and recompileit lirary?
Much easier to use the debug CRT library and step into it with the debugger.
Surely if you have the CRT source code to do a rebuild, you should be able to
step into the debug build of the library
Also, if you don't like the performance of fopen/fclose file I/O, there are other options...
like direct Win32 calls.
If you don't want data to be buffered, you'll need to use unbuffered I/O
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Thanks Mark.
Each of your message helping me to get close of the problem.
I tried to put some OutputDebugString message in fclose.c . Now I am not able to find the way by which I can compile this file.Could you please tell that how can I do this?
other thing. Is there difference ,If I create the file by giving name either "a.dat" or "a.log" . creating log file by name *.dat makes any differnece in internal handling of file.
I have also observed that this problem is not happening on my local m/c.It is happening only on live system and that m/c is on windows server 2003.So fclose is related to OS?
Thanks,
Vishal
|
|
|
|
|
I have tried by giving "c"in mode while opening the file.I fflush before closing the file.It returned immidately.
So I think fflush is not culprit here.
As per fclose code.It does following four steps
1 flush
2 free buffer
3 close file
4 delete temp file.
I think it might be something related to free buffer.
Thanks
Vishal
|
|
|
|
|
Vishal Kumar Soni wrote: I think it might be something related to free buffer.
Were you able to step into the code or are you guessing?
Like I said, if the buffering implementation doesn't perform
the way you need it to, then you need to use a different I/O method.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
It was guess.
I have also tried by setvbuf to set the buffer to zero.It is also not helping.
Other strange thing I found that,if I right click on that file to see properties even then it is taking long time rahter then othe files with same size on same location.
Could you please tell the way by which I can step in to fopen code to put some debug message?
Thanks,
Vishal
|
|
|
|
|
You can also try using setvbuf()[^] to use a smaller buffer size (or no buffering).
I don't recall what the default buffer size is.
Something's really wrong somewhere if it's taking minutes to close a file of a
couple hundred MBs.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I have found something related to this problem.I talk with neotwork and admin guys and requested them to turn off the antivirus on that m/c.After that it worked fine.So it might be due antivirus we were not able to close this file.I will test this 1 day then I will confirm.
Thanks lot!
Regards,
Vishal
|
|
|
|
|
Oh yeah - antivirus software will slow it way down
As far as stepping into CRT/MFC code....
Make sure you are linking to the debug version of the library(s).
Put a breakpoint on the fclose() call.
Run in debugger.
When the breakpoint is hit, use F11 to step into the library code.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|