|
OK
Remember to start a worker thread before the call and monitor it.
Best Wishes and Happy Holiday's,
ez_way
|
|
|
|
|
There seems to be a lot of articles written which promote the use of storing DHTML data from a C++ application in memory, rather than reading/writing temporary files to disk. However, there doesn't appear to be a lot of support backing this "best-practices" theory, other than disk caching seems slower or more sloppy (for lack of a better word) than memory caching, and that the temporary files will need to be deleted afterwards. I'm going to have to raise a brow on this one and get some others thinking about it before we all start writing a bunch of applications based on this memory usage theory.
The idea is that by initially navigating to "about:blank" and insuring that the document is loaded, we can then write directly to the HTML document as it sets in memory. The alternative approach obviously, is to write to a temporary file that is stored on the hard disk, "C:\\temp\\temp.htm" for example. I've looked deeply into both of these methods and I have to say that I'm leaning a little towards the disk caching but maybe someone can raise a point that I haven't considered.
Firstly, most of the articles claim that there'd be a need to write temporary "files" (plural), which is a little misleading. If you can write your entire DHTML document to one "about:blank", then you should be able to write the same content to one "temp.htm".
In terms of clean-up, deleting a temporary file is no different than releasing values stored in memory and Microsoft has confirmed that there are issues with releasing BSTR's from memory, even in Internet Explorer, which is causing memory leaks in most of these memory-based solutions. Simply put, a rebel file will cause far less damage than an orphaned memory block. After all and in most cases, we have Gig's worth of free and available disk space to work with and only a few hundred Meg's worth of memory, not to mention the fact that that few hundred MB's is being shared with the operating system and all of the other applications that are running on the desktop and using memory.
Additionally, the nature of a Microsoft OS is to buffer memory in an out of a paging file, so the data is eventually going to be written to the disk anyway, and into a space that is restricted by the amount of memory that is available to the system. True, the OS will "take care of it for you" but when you let something else take care of something for you, you give up the control you have over how it's handled.
And does your file need to be temporary? Do you even need to delete the file? In some cases, it may be advantatious to have a file still cached on the disk, to allow the users to work "off-line" for example, or if there's an Internet gliche and some of the data that you're attempting to download is unavailable, you can resort back to the cached file and let the end-user know that it's old data. If everything is stored in memory however, it's lost (hopefully) when they close the application. If the data they need is unavailable the next time they fire it up, they get nothing.
As far as speed goes, the disk reader and the ribbon cable slow the data down a little but the data, whether traveling from the RAM or the hard disk, will most likely bottleneck on the system bus, especially if there are a lot of other applications/services running and it's rush hour and everybody wants to go to CPU Town.
Disk access speed has increased right along with all of the other processing speeds over the years and frankly, I'd rather my customers complain about my application being a little slower in response time (if it's even noticable) than spreading around words and phrases about my application like "resource hog" and "memory leaks", which can be a deal breaker.
Besides that, the less memory that the system has available, the longer the computer will take to process data and the slower the machine will be overall, so instead of just having a slightly slower application, you're stepping on the turf of other applications and slowing down the whole system by storing large amounts of data in memory.
And finally, Microsoft itself uses temporary Internet files for caching information and they've developed both the Operating System and a pretty popular little web browser too, so maybe they know something we don't know?
Whether stored in memory or on disk, it's the same number of 1's and 0's either way you slice it. The only disadvantage that I can see with storing this type of data on disk is a slightly slower response time but I'm not even sure that it would be enough of a difference that would be noticable by the human eye, which is obviously the most important aspect, what is presented to the end-user. And storing this same data in memory can ramify into more problems which could have a negative impact on the entire sytem.
All things considered and in conclusion, wouldn't it be best to store DHTML data on disk rather than in memory?
Thoughts, ideas, retorts?
Cheers,
Wolf
"Anything's possible if you don't know what you're talking about."
- Green's Law of Debate
|
|
|
|
|
WolfSupernova wrote:
Disk access speed has increased right along with all of the other processing speeds over the years and frankly, I'd rather my customers complain about my application being a little slower in response time (if it's even noticable) than spreading around words and phrases about my application like "resource hog" and "memory leaks", which can be a deal breaker.
You know why they complain about having less memory on their machines? It's because, when you don't have enough memory available, the OS will use the disk.
The current fastest disks are still at least 1,000 times slower than the current slowest memory chips.
I don't really know what are the issues about storing DHTML files in memory, but, basically, what you are asking is: is it worthy have a slightly faster software, but leaky?
OTOH, a browser builds an in-memory copy of everything that you ask it to read from the disk. Build a large test file and ask for IE to open it and you'll understand what I mean. So, storing a DHTML on disk for viewing won't save you memory, unless you have bugs.
Trying to make bits uncopyable is like trying to make water not wet.
-- Bruce Schneier
By the way, dog_spawn isn't a nickname - it is my name with an underscore instead of a space. -- dog_spawn
|
|
|
|
|
WolfSupernova wrote:
After all and in most cases, we have Gig's worth of free and available disk space to work with and only a few hundred Meg's worth of memory
You may, I don't. Just like a gas, my file storage fills to all available space. I keep having to delete stuff so I can put new stuff on.
WolfSupernova wrote:
And does your file need to be temporary?
I sure hope so! I don't need tons of small files filling my temp directory! I hourly clean out my temp directory. The more files you have in a directory, the slower it is to locate them. Microsoft has a scheme whereby they break up the Temporary Internet Files in multiple directories and then have a file that it searches to find the actual file.
WolfSupernova wrote:
And finally, Microsoft itself uses temporary Internet files for caching information and they've developed both the Operating System and a pretty popular little web browser too, so maybe they know something we don't know?
Sure, like how to cache web files between computer reboots. If you're just going to show a file thats generated on the fly, why cache it? In fact, IE won't cache certain files that a website flags as being generated on the fly.
WolfSupernova wrote:
Firstly, most of the articles claim that there'd be a need to write temporary "files" (plural), which is a little misleading. If you can write your entire DHTML document to one "about:blank", then you should be able to write the same content to one "temp.htm".
So, you can write out all the images into the DHTML as well? That'd be a neat trick. And it'd bloat your html page too.
So, my opinion is, the amount of memory needed for small files to be placed into an IE window is small and insignificant and is best suited for storing in memory. IE probably won't cache it anyways if it's on the file system.
But don't get me wrong, it depends on what you're doing. Not all apps should keep everything in memory. I just feel that most of the apps write out a small amount of html anyways. I've found other solutions for displaying html, like QHTM, HtmlLayout, or PBears THtmlViewer.
YMMV, but mine is sticking to memory. A hard drive is for persistent data.
--
Joel Lucsy
|
|
|
|
|
Unable to open resources!![^]
Can someone please help me figure this one out?
"We have done so much in the last 2 years, and it doesn't happen by standing around with your finger in your ear, hoping everyone thinks that that's nice." - Donald Rumsfeld
|
|
|
|
|
Nevermind. Found the answer here[^].
"We have done so much in the last 2 years, and it doesn't happen by standing around with your finger in your ear, hoping everyone thinks that that's nice." - Donald Rumsfeld
|
|
|
|
|
Ain't that a lovely bug?
The workaround I have a little simpler, requires no monkeying with include paths.. but then again I can't guarantee it will work under all circumstances. Just close your "solution", open the RC file itself, and then reopen the "solution".. the resource file will now be editable.
|
|
|
|
|
This does not belong here.
Best Wishes and Happy Holiday's,
ez_way
|
|
|
|
|
Why on earth not? It's a VC issue...
BTW - that's "Happy Holidays", as long as we're being pedantic.
|
|
|
|
|
I thought that I had a handle on the dll building.
But now when I try to use a dll that is not in the
same project then I get the Unresolved External error.
I can add a project to the dll project and include the
header and go no problem. I have made my own include and
lib dirs and added them to visual studio's list. Then
added the header and lib files. Is there something
that I am missing?
Thank You
Bo Hunter
|
|
|
|
|
Interesting. Given that the DLL is compiled and you import the DLL library into the project, then it should compile.
Kuphryn
|
|
|
|
|
Hi, I really nead a C (not c++) code for deconvolution of signals (not images)using fft.
Is there anybody that can help me? I'll be very happy.
Thanks, Angeluna.
|
|
|
|
|
Hi
have you looked at
http://www.fftw.org/
?
Best Wishes and Happy Holiday's,
ez_way
|
|
|
|
|
I have a modeless dialog that can be dismissed with an "enter" (didnt override the onOK()). At this point I want to delete the pointer to the d iaolg I got with new. where should "delete this;" go? In the destructor of the class or postncdestroy? Which is the correct place?
thanks,
ns
|
|
|
|
|
ns wrote:
Which is the correct place?
PostNcDestroy().
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Hi
Do the deed in OnDestroy
if(pointername)
pointername = NULL;
You will get a leak if you do not set to null.
The frame will kill it on exit once it is set to null.
Best Wishes and Happy Holiday's,
ez_way
|
|
|
|
|
I have a question, can I use MAPI to add extra functions to Outlook Express (not Outlook).
|
|
|
|
|
Do you mean adding extra functionality to OE? If yes, then no. MAPI can be used to programmatically do what OE does.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
 I have been trying for the last week to print a bitmap in colour unsuccessfully. If anyone can help I would be eternally grateful. The bitmap prints but only in black and white. Below is the code I am using:
BOOL CControlImpresion::ImprimeAImpresora()
{
HDC hdcPrinter;
HDC hdcBmp;
HDC hdc2Bmp;
HBITMAP hOldBitmap;
HBITMAP hOldBitmap2;
HBITMAP hBMP;
HANDLE hPRN;
LONG dpBytesNeeded;
LPDEVMODE lpDevMode;
DOCINFO DocInfo;
SIZE PrinterDimensions;
SIZE BitmapDimensions;
POINT PrinterPosition;
BITMAP Bitmap;
RECT BMPSize;
HDC hDC;
HDC hMemDC;
HGLOBAL hMem;
HBITMAP hNewBitmap;
HBITMAP hBitmap;
BITMAPINFOHEADER BitmapInfoHeader;
LPBITMAPINFOHEADER lpBitmapInfo;
BITMAPINFO BitmapInfo;
LPVOID lpBitBuffer;
/********************************************************************************************/
// ABRIMOS LA IMPRESORA Y OBTENEMOS SU DC
/********************************************************************************************/
// Obtenemos un handle a la impresora:
if (!OpenPrinter((LPTSTR)m_szPrinterName,(LPHANDLE)&hPRN,NULL))
return FALSE;
// Hacer que imprima apaisado y el número de copias establecido
dpBytesNeeded = DocumentProperties(NULL,hPRN,(LPSTR)m_szPrinterName,NULL,NULL,0);
if (!(lpDevMode = (LPDEVMODE)LocalAlloc(LPTR,dpBytesNeeded)))
return FALSE;
if (DocumentProperties(NULL,hPRN,(LPSTR)m_szPrinterName,(PDEVMODE)lpDevMode,NULL,DM_OUT_BUFFER) != IDOK)
return FALSE;
lpDevMode->dmOrientation = DMORIENT_LANDSCAPE;
lpDevMode->dmCopies = m_iNumeroCopias;
lpDevMode->dmFields = DM_ORIENTATION | DM_COPIES;
if (DocumentProperties(NULL,hPRN,(LPSTR)m_szPrinterName,(PDEVMODE)lpDevMode,(PDEVMODE)lpDevMode,DM_IN_BUFFER|DM_OUT_BUFFER) != IDOK)
return FALSE;
// Creamos el DC para la impresora:
if (!(hdcPrinter = CreateDC(m_szPrinterDriver,m_szPrinterName,NULL,(CONST DEVMODE *)lpDevMode)))
return FALSE;
/*********************************************************************************************/
// Obtenemos las dimensiones de la impresora
PrinterDimensions.cx = GetDeviceCaps(hdcPrinter, HORZRES);
PrinterDimensions.cy = GetDeviceCaps(hdcPrinter, VERTRES);
/*********************************************************************************************/
// OBTENEMOS LA CAPTURA DE LA PANTALLA
/********************************************************************************************/
hDC = CreateDC("DISPLAY",0,0,0);
BMPSize.left = BMPSize.top = 0;
BMPSize.right = GetDeviceCaps(hDC, HORZRES);
BMPSize.bottom = GetDeviceCaps(hDC, VERTRES);
hMemDC = CreateCompatibleDC(hDC);
hNewBitmap = CreateCompatibleBitmap(hDC,BMPSize.right,BMPSize.bottom);
hOldBitmap = (HBITMAP)SelectObject(hMemDC, hNewBitmap);
if (!BitBlt(hMemDC,0,0,BMPSize.right,BMPSize.bottom,hDC,jmx_xstartcoord,0,SRCCOPY))
return FALSE;
/********************************************************************************************/
/*********************************************************************************************/
// CREAMOS UN BITMAP COMPATIBLE CON EL DC DE LA IMPRESORA A PARTIR DE LA CAPTURA
/*********************************************************************************************/
BitmapInfoHeader.biSize = sizeof(BITMAPINFOHEADER);
BitmapInfoHeader.biWidth = BMPSize.right;
BitmapInfoHeader.biHeight = BMPSize.bottom;
BitmapInfoHeader.biPlanes = 1;
BitmapInfoHeader.biBitCount = 16;
BitmapInfoHeader.biCompression = BI_RGB;
BitmapInfoHeader.biSizeImage = 0;
BitmapInfoHeader.biXPelsPerMeter = 0;
BitmapInfoHeader.biYPelsPerMeter = 0;
BitmapInfoHeader.biClrUsed = 0;
BitmapInfoHeader.biClrImportant = 0;
BitmapInfo.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
BitmapInfo.bmiHeader.biWidth = BMPSize.right;
BitmapInfo.bmiHeader.biHeight = BMPSize.bottom;
BitmapInfo.bmiHeader.biPlanes = 1;
BitmapInfo.bmiHeader.biBitCount = 16;
BitmapInfo.bmiHeader.biCompression = BI_RGB;
BitmapInfo.bmiHeader.biSizeImage = 0;
BitmapInfo.bmiHeader.biXPelsPerMeter = 0;
BitmapInfo.bmiHeader.biYPelsPerMeter = 0;
BitmapInfo.bmiHeader.biClrUsed = 0;
BitmapInfo.bmiHeader.biClrImportant = 0;
// Establecemos la memoria para el bitmap
hMem = GlobalAlloc(GHND,BitmapInfo.bmiHeader.biSize);
// Bloqueamos la memoria y obtenemos un puntero
lpBitmapInfo = (LPBITMAPINFOHEADER)GlobalLock(hMem);
// Guardamos la info del bitmap que hemos preparado
*lpBitmapInfo = BitmapInfo.bmiHeader;
// Calculamos la dimension del bloque de memoria requerido por la imagen
GetDIBits(hMemDC,hNewBitmap,0,(UINT)BitmapInfo.bmiHeader.biHeight,NULL,(LPBITMAPINFO)lpBitmapInfo,DIB_RGB_COLORS);
BitmapInfo.bmiHeader = *lpBitmapInfo;
GlobalUnlock(hMem);
GlobalFree(hMem);
hMem = GlobalAlloc(GHND,BitmapInfo.bmiHeader.biSizeImage);
lpBitBuffer = (LPVOID)GlobalLock(hMem);
// Obtenemos los bits del bitmap
if (GetDIBits(hMemDC,hNewBitmap,0,(UINT)BitmapInfo.bmiHeader.biHeight,lpBitBuffer,(LPBITMAPINFO)&BitmapInfo.bmiHeader,DIB_RGB_COLORS) == 0)
{
// Nos salimos si hay errores
GlobalUnlock(hMem);
DeleteDC(hMemDC);
DeleteDC(hDC);
return FALSE;
}
if ((hBitmap = CreateDIBitmap(hdcPrinter,&BitmapInfoHeader,CBM_INIT,lpBitBuffer,&BitmapInfo,DIB_RGB_COLORS)) == NULL)
{
// Nos salimos si hay errores
GlobalUnlock(hMem);
DeleteDC(hMemDC);
DeleteDC(hDC);
return FALSE;
}
GlobalUnlock(hMem);
/* PBITMAPINFO pBitmapInfo;
PBITMAPINFOHEADER pBitmapInfoHeader;
pBitmapInfo = CreaBitmapInfo(hBitmap);
CreaBMP(".\\bmpFile.bmp",pBitmapInfo,hBitmap,hMemDC);
LPBYTE lpBits;
PBITMAPINFO pbi;
pbi = pBitmapInfo;
pBitmapInfoHeader = (PBITMAPINFOHEADER)pbi;
// Reservamos memoria para los bytes del bitmap
if ((lpBits = (LPBYTE)GlobalAlloc(GMEM_FIXED,pBitmapInfoHeader->biSizeImage)) == NULL)
return FALSE;
// Obtenemos el color table (RGBQUAD array) y los bits
if (!GetDIBits(hdcPrinter,hBitmap,0,(WORD)pBitmapInfoHeader->biHeight,lpBits,pbi,DIB_RGB_COLORS))
{
GlobalFree(lpBits);
return FALSE;
}*/
DeleteDC(hMemDC);
DeleteDC(hDC);
// Recuperamos la info del bitmap
if (!GetObject(hBitmap,sizeof(Bitmap),(LPSTR)&Bitmap))
return FALSE;
/*********************************************************************************************/
/*********************************************************************************************/
// AMPLIAMOS LA IMAGEN A LAS DIMENSIONES ADECUADAS A LA IMPRESORA E IMPRIMIMOS
/*********************************************************************************************/
// Calculamos las dimensiones de ampliacion para evitar que la imagen se achate
BitmapDimensions.cy = PrinterDimensions.cy;
BitmapDimensions.cx = Bitmap.bmWidth * (PrinterDimensions.cy / Bitmap.bmHeight);
// Calculamos la posicion de impresion, para que salga la imagen centrada sobre el papel
PrinterPosition.y = 0;
PrinterPosition.x = (PrinterDimensions.cx / 2) - (BitmapDimensions.cx / 2);
// DC origen con la captura
hdcBmp = CreateCompatibleDC(hdcPrinter);
hOldBitmap = (HBITMAP)SelectObject(hdcBmp,hBitmap);
/* PBITMAPINFO pBitmapInfo;
pBitmapInfo = CreaBitmapInfo(hBitmap);
CreaBMP(".\\bmpFile.bmp",pBitmapInfo,hBitmap,hdcPrinter);*/
// DC destino con la imagen ampliada
hdc2Bmp = CreateCompatibleDC(hdcBmp);
hBMP = CreateCompatibleBitmap(hdc2Bmp,BitmapDimensions.cx,BitmapDimensions.cy);
hOldBitmap2 = (HBITMAP)SelectObject(hdc2Bmp,hBMP);
// Ampliamos la captura para ajustarla al tamaño de la impresora
SetMapMode(hdc2Bmp,MM_TEXT);
if (!SetStretchBltMode(hdc2Bmp,HALFTONE))
return FALSE;
if (!SetBrushOrgEx(hdc2Bmp,0,0,NULL))
return FALSE;
if (!StretchBlt(hdc2Bmp,0,0,BitmapDimensions.cx,BitmapDimensions.cy,hdcBmp,0,0,Bitmap.bmWidth,Bitmap.bmHeight,SRCCOPY))
return FALSE;
// Establecemos la info del documento a imprimir
DocInfo.cbSize = sizeof(DOCINFO);
DocInfo.lpszDocName = "Impresión de P.I.: Captura de pantalla";
DocInfo.lpszOutput = NULL;
/* PBITMAPINFO pBitmapInfo;
pBitmapInfo = CreaBitmapInfo(hBitmap);
CreaBMP(".\\bmpFile.bmp",pBitmapInfo,hBitmap,hdcPrinter);*/
// Imprimimos
StartDoc (hdcPrinter, &DocInfo);
StartPage (hdcPrinter);
// El BitBlt funciona
if (!BitBlt(hdcPrinter,PrinterPosition.x,PrinterPosition.y,BitmapDimensions.cx,BitmapDimensions.cy,hdc2Bmp,0,0,SRCCOPY))
return FALSE;
/* PBITMAPINFO pBitmapInfo;
pBitmapInfo = CreaBitmapInfo(hBitmap);
CreaBMP(".\\bmpFile.bmp",pBitmapInfo,hBitmap,hdcPrinter);*/
// Finalizamos la impresion
EndPage (hdcPrinter);
EndDoc (hdcPrinter);
hBitmap = (HBITMAP)SelectObject(hdcBmp,hOldBitmap);
hBMP = (HBITMAP)SelectObject(hdc2Bmp,hOldBitmap2);
// Liberamos los DC
DeleteDC(hdcPrinter);
DeleteDC(hdcBmp);
DeleteDC(hdc2Bmp);
// Liberamos la memoria
LocalFree(lpDevMode);
// Cerramos la impresora
ClosePrinter(hPRN);
return TRUE;
}
|
|
|
|
|
I am relatively new to programming and i need help on coding for state flags. my problem is:
I want to set a state flag which sort of act as a switch for my onpaint() to be executed after my dialog has beem accessed in SDI. How do i code that line in my dialog and Onpaint(). Also, by doing this, will my onpaint() be able to access the updated values in the dialog? (as i need these values in order to draw).will greatly appreciate any kind help.
|
|
|
|
|
If I understand your question, you need a member variable in your CView-derived class. That member variable can then be accessed/changed in any of the methods of the derived class.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
yah something like that, do I add it as member variable to both view and all dialog classes using the "add member variable" in the class view tab and of type:boolean and public? Also , i have another problem: i need the current values of the dialog in order to draw to SDI view, but first i want to capture these values in the SDI doc class, how do i code that assumming the values needed are length, breadth from dialog A. The dialogs are modal.
|
|
|
|
|
In previous versions of the MFC calling COleDateTime::Format with no parameters would return the date formated according to the locale.
In MFC7 this no longer works. It gives the time one hour too early.
I just post this incase anyone is migrating their code to VS.NET to be warned.
Ed
|
|
|
|
|
Does the locale your system thinks you are in operate any kind of daylight saving?
Steve S
|
|
|
|
|
If we're talking about the overload of COleDateTime::Format which takes a DWORD and an LCID (which I think we are), both implementations (MFC 6 and ATL/MFC 7) call the Windows API function VarBstrFromDate, with the same parameters, in the same order. Despite a few class changes to reuse CComBSTR rather than a full-on VARIANT, it's pretty much the same.
However, the implementation of COleDateTime::operator=(const time_t) has changed. The old implementation included a local time conversion (through the localtime function) from a time_t to a struct tm, then through the helper function _AfxOleDateFromTm which performs the computations to produce an Automation-compatible DATE value.
The new implementation stores the supplied time value as a CTime, then uses CTime::GetAsSystemTime to produce a SYSTEMTIME, which is passed to SystemTimeToVariantTime - the OS computes the DATE value, not MFC.
This difference affects the behaviour of COleDateTime::GetCurrentTime in that it now returns an object with the current UTC time, not the local time. If you need the local time, use GetLocalTime, then convert the resulting SYSTEMTIME structure using the appropriate COleDateTime constructor or assignment operator.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
