|
Both are dialog based applications. Test program contains only one radio button.
In main program there are lot of controls and work against them
|
|
|
|
|
As you can see yourself, the code works.
So that means what you've done is correct.
That must mean, there is something else going wrong in the first program.
Maybe a wrong ID has been used.
You could debug the code to get the answer.
|
|
|
|
|
The font is set but text color is not set in first program.
This is the problem with radio buttons. If i add a new radio button then also text color is not set.
But for static control the text color is set.
It means something needs to be supported for radio button
|
|
|
|
|
I found the reason why.I am using XP theme. Below url also says that
http://www.go4expert.com/forums/showthread.php?t=16457&page=2
If i remove xp theme then color is set for radio text.
Is there any solution for that problem.It's require for me to use XP theme.
XP theme
="1.0"="UTF-8"="yes"
<assembly
xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
<assemblyIdentity
processorArchitecture="x86"
version="5.1.0.0"
type="win32"
name="appname.exe"/>
<description>appname</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
publicKeyToken="6595b64144ccf1df"
language="*"
processorArchitecture="x86"/>
</dependentAssembly>
</dependency>
</assembly>
|
|
|
|
|
Hi all,
I just want to know one thing that when we insert items in List Control its memory increases by 4k. I wanted to know that this memory increase also depends on number of columns we insert in each row.
Thanks in advance
|
|
|
|
|
Did you give it a try? I mean just include another column and see for yourself
I know I am coward since the day I know that fortune favors the brave
|
|
|
|
|
Hi all
I have the following code
CString s;
s = "CSECT";
do {
memset(&buffer[0],0x20,121);
pFile->ReadString(&buffer[0],123);
} while(s.Find((LPCTSTR) &buffer[0]) == -1);
When buffer has the following the return code remains -1
000000 00000 000BC 10 TESTA CSECT
|
|
|
|
|
As I read the docco[^], you've got your find inside-out. Your code is looking for the contents of the buffer inside "CSECT". No great surprise that it's not found.
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
|
Several things could be going wrong here.
First - As Peter said, you've got it inside out.
Second - Even though you're assigning a non-unicode string to a CString object, it would be converted to a unicode string if you're doing a unicode build.
Third - Looks like the buffer contains binary data. If so, it would not work with a string object since it would look at a 0 as the null terminating character to end the string.
So, I recommend you use the memcmp function to find the string - memcmp(buffer, (LPVOID)(LPCTSTR)s, 121);
|
|
|
|
|
Hello,
is there a convenient way to pass a pointer to a data member so that it is recognized as a template argument?
The following does not compile under VC++ 2008:
template<class Parent, typename Type, Type Parent::*Member>
void AddMember(Type Parent::*Member)
{
return true;
}
...
AddMember(&TestObject::i);
Alex
|
|
|
|
|
Not completely sure... but did you try just this:
void AddMember(Type *Member)
If you're calling a method for it, no need to specify Parent::*Member, where the pointer comes from is up to the caller.
|
|
|
|
|
Try this -
template<class Parent, typename Type>
void AddMember(Type Parent::*Member)
{
return true;
}
|
|
|
|
|
Thank you for your answers.
Please look at this example:
struct TestObject
{
int i;
};
template<int TestObject::*Member>
void test() {}
...
test<&TestObject::i>();
This way, I can call the function template so that the member pointer is passed as a (non-type) template argument. However, in my case, I would like that parent and type are template parameters, too:
struct TestObject
{
int i;
};
template<class Parent, typename Type, Type Parent::*Member>
void test() {}
...
test<Testobject, int, &TestObject::i>();
However, this is not very convenient to call test() as you have to specify all template arguments manually.
If you pass &TestObj::i as a argument to the function, Parent and Type are deduced - but not the Member...
Alex
|
|
|
|
|
I understand that you want the parent and type to be template parameters.
So let me repeat my earlier code snippet -
template<class Parent, typename Type>
void AddMember(Type Parent::*Member)
{
return true;
}
Here Parent and Type are template parameters and the calling is also convenient - AddMember(&TestObject::i);
Here Parent will be deduced to TestObject and Type will be deduced to int .
And Member will point to i .
I think this is as convenient as it can get.
|
|
|
|
|
I'm having trouble either launching the 2 correctly, or getting them to run together, not sure which one.
I want to run a fake progress bar update, and run a program in cmd.exe together at the same time.
This current code runs the CreateProcess, and before I wait for the Process, I create a thread to run the progress program. The process runs, and then the progress program runs when the process is complete. I'm trying to run them simultaneously. I'm not waiting for the progress bar to finish, because it's decorative.
if (CreateProcess( lpFile_Create, szParameters_Create, NULL, NULL, FALSE, CREATE_NO_WINDOW, 0, szWindowsTempDir, &si, &pi) )
{
PIIS7_INSTALL_PROGRESSDATA pDataArray;
pDataArray = (PIIS7_INSTALL_PROGRESSDATA) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
sizeof(IIS7_INSTALL_PROGRESSDATA));
if( pDataArray == NULL )
{
ExitProcess(2);
}
else {
pDataArray->hStatusMessage = pzStatusMessage;
pDataArray->hProgressBar = pzProgressBar;
hProgressBar = CreateThread( NULL, 0, CA_IIS7_ProgressBar_Install, pDataArray, 0, dwProgressBarID );
}
WaitForSingleObject(pi.hProcess, INFINITE);
GetExitCodeProcess(pi.hProcess, (unsigned long *)&exitstatus);
CloseHandle(hProgressBar);
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
if(pDataArray != NULL)
{
HeapFree(GetProcessHeap(), 0, pDataArray);
pDataArray = NULL;
}
|
|
|
|
|
Did you state what the problem is? My apologies if I missed it.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I can get the CreateProcess to go, or the CreateThread, but not both.
|
|
|
|
|
So when the process starts, and it gets to the CreateThread call, did you call GetLastError to see why CreateThread fails?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Could it be that since you're blocking the thread in the WaitForSingleObject function, that the program is unable to process the window messages necessary to update the progress bar?
And then when the main thread is released, all the messages are processed?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I think your right. But I'm not sure in how to proceed, I was thinking WaitForMultiple, but I thought it was only for threads with the same handle.
Would it be possible to offer a hint?
|
|
|
|
|
Just offhand, I would say try creating the secondary thread first, then launch the process from the secondary thread. That way the secondary thread can wait for the process to finish, and your main thread can update the progress bar.
Then the secondary thread can alert the main thread that the process is finished by posting a custom message to its main window.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
OK, Let me give that a whirl. I added the error code, and it was 87, I will look that up.
|
|
|
|
|
How did you verify it?
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 no error 87 on the progress thread.
I used SetLastError for 0, then asked for the error again after Creating the thread.
The progress thread runs, just can't send a SetWindowText or SendMessage out of it.
I'll see if there is an error.
|
|
|
|