C / C++ / MFC

Re: Making Desktop application flexible to monitor resolution

17-Feb-10 3:46

As I know
there is no automation from the MFC side here... Smile | :)

So you could check it explicitly,
for example - by sizing of the frame - like this:

if (pcBar->IsThereNoSpace()) {
  pcBar->ReDock();
}

Rakesh517-Feb-10 4:17

Rakesh5

17-Feb-10 4:17

Hello sir,

Are IsThereNoSpace() and ReDock() MFC Functions???

If not, can u please tell me the definition of the functions??

thanks,
rakesh.

Re: Making Desktop application flexible to monitor resolution

Eugen Podsypalnikov17-Feb-10 4:21

Re: Making Desktop application flexible to monitor resolution

17-Feb-10 4:21

Hello Rakesh,

no, sorry,
there are function GetWindowRect(..)
and nember functions of your ToolBar class only... Smile | :)

Do you use CMFCToolBar in your application ?
Eugen

BonshatS17-Feb-10 14:33

BonshatS

17-Feb-10 14:33

These sites might be of some use :

Writing High-DPI Win32 Applications[^]

Tutorial: Writing High-DPI Win32 Applications[^]

DLL and .Exe

ramina sen17-Feb-10 2:15

ramina sen

17-Feb-10 2:15

what are the diffaence between .exe and .dll
While developing a com componet which is best pratice ..should u go for .exe or .Dll?????

Game-point17-Feb-10 3:35

Game-point

17-Feb-10 3:35

DLL is the Best practice for all time ..because its safe and secured.

An exe is executable programs and DLL is file that can be loaded and executed dynamically.
DLL doesnot have main Function and exe have..

Failure is Success If we learn from it!!

Eugen Podsypalnikov17-Feb-10 3:36

17-Feb-10 3:36

It is easier to begin by a DLL
if you will not use DCOM... Smile | :)

A DLL component will be faster
but more dangerous (by errors) for a client.

An EXE component could be a service Smile | :)

BIJU Manjeri17-Feb-10 16:40

BIJU Manjeri

17-Feb-10 16:40

COM servers come in two basic varieties: in-process and out-of-process. In-process servers (often referred to as in-proc servers) are DLLs. They're called in-procs because in the Win32 environment, a DLL loads and runs in the same address space as its client. EXEs, in contrast, run in separate address spaces that are physically isolated from one another. In most cases, calls to in-proc objects are very fast because they're little more than calls to other addresses in memory. Calling a method on an in-proc object is much like calling a subroutine in your own application.

Out-of-process servers (also known as out-of-proc servers) come in EXEs. One advantage to packaging COM objects in EXEs is that clients and objects running in two different processes are protected from one another if one crashes. The disadvantage is speed. Calls to objects in other processes are roughly 1,000 times slower than calls to in-proc objects because of the overhead incurred when a method call crosses process boundaries.

Please refer Programming Windows with MFC by Jeff Prosise ->COM

How to load a bitmap into a Toolbar from Resource Manager?

Saurabh.Garg17-Feb-10 17:10

Saurabh.Garg

17-Feb-10 17:10

Given that code is same how can DLL be faster then EXE.

-Saurabh

Software200717-Feb-10 2:07

Software2007

17-Feb-10 2:07

If I already have a bitmap, how can I add that bitmap to the toolbar, right now, I can copy and paste it into the toolbar, but it comes out in different colors. I do not want to redraw it, what am I missing?

Thanks

Re: How to load a bitmap into a Toolbar from Resource Manager?

Eugen Podsypalnikov17-Feb-10 3:26

CRITICAL SECTION AND MUTEX

17-Feb-10 3:26

You could try to do it by MS Paint
and then save it as 24-bit bitmap... Smile | :)

ramina sen17-Feb-10 0:58

ramina sen

17-Feb-10 0:58

where to use critical section and where to use mutex ..
wat is best pratices ..to use this syncronisation elements .

Re: CRITICAL SECTION AND MUTEX

Adam Roderick J17-Feb-10 1:13

Adam Roderick J

17-Feb-10 1:13

I think you read this section to know which to use at what time[^]

Величие не Бога может быть недооценена.

Re: CRITICAL SECTION AND MUTEX

Roger Stoltz17-Feb-10 1:40

Roger Stoltz

17-Feb-10 1:40

For thread synchronization between threads in the same process you should use critical sections as they are faster since they don't have a kernel object associated with them.
For synchronization between processes, e.g. when accessing system resources, you have to use mutexes.
Mutexes will work in either case.

You will find some interesting reading here[^] and here[^].

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

Re: CRITICAL SECTION AND MUTEX

Cool_Dev17-Feb-10 22:16

Cool_Dev

17-Feb-10 22:16

critical section can be used to provide synchronization in single process only, so they are faster. Mutex can be used to provide synchronization among different processes..

problem in updating the icon

learningvisualc16-Feb-10 23:38

learningvisualc

16-Feb-10 23:38

Hi all,

i want to replace a exe default icon with any other icon. i have written this code to do this

HANDLE hFile;
DWORD dwFileSize,  dwBytesRead;
LPBYTE lpBuffer;
HANDLE hResource;
	
HRSRC hRes;         // handle/ptr. to res. info. in hExe 
HANDLE hUpdateRes;  // update resource handle 
char *lpResLock;    // pointer to resource data 
HRSRC hResLoad;     // handle to loaded resource 
BOOL result; 
HMODULE hSrcExe,hDestExe;
int iLoop;

hFile = CreateFile("E:\\icon.ico", 
		GENERIC_READ,
		FILE_SHARE_READ,
		NULL,
		OPEN_EXISTING,
		FILE_ATTRIBUTE_NORMAL,
		NULL);

if (INVALID_HANDLE_VALUE != hFile)
{
	dwFileSize = GetFileSize(hFile, NULL);
	lpBuffer = new BYTE[dwFileSize];
	int aa = ReadFile(hFile, lpBuffer, dwFileSize, &dwBytesRead, NULL);
	hResource = BeginUpdateResource("E:\\xyz.exe", FALSE);

	if (NULL != hResource)
	{
		if (UpdateResource(hResource,
				RT_ICON,
				MAKEINTRESOURCE(1),
				MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
				(LPVOID) lpBuffer,
				dwFileSize) != FALSE)
			{        
				EndUpdateResource(hResource, FALSE);
			}
	}
}

but its not updating the icon...

I am not getting where is the problem. Can anybody help me in this...

Thanks in advance

Richard MacCutchan17-Feb-10 0:59

Richard MacCutchan

17-Feb-10 0:59

You do not check the return status from your commands, apart from not executing the UpdateResource()<code> or EndUpdateResource() functions if an error occurs. You should run your code through the debugger to see if everything gets executed correctly, and if not, check any error codes by using GetLastError().

txtspeak is the realm of 9 year old children, not developers. Christian Graus

learningvisualc17-Feb-10 1:34

learningvisualc

17-Feb-10 1:34

i have seen that everthing is executing fine, then also icon is not getting replaced.

Richard MacCutchan17-Feb-10 3:07

Richard MacCutchan

17-Feb-10 3:07

learningvisualc wrote:
i have seen that everthing is executing fine, then also icon is not getting replaced.

Sorry, but I cannot think of anything else to suggest, other than to check that you are using the correct resource id in the destination executable. If each function returns success status then it should work.

txtspeak is the realm of 9 year old children, not developers. Christian Graus