|
Oh yes, first have a look at the color, it is very important, then, in the spare, time you may also check how many wires the cable has.
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]
|
|
|
|
|
CPallini wrote: ...you may also check how many wires the cable has.
How's he supposed to know that until he first knows how many ends the cable has?
"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
|
|
|
|
|
Uh, has the cable actually ends?
BTW welcome in the THHB , David [^].
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]
modified on Thursday, October 30, 2008 4:48 PM
|
|
|
|
|
CPallini wrote: Uh, has the cable actually ends?
Yes, some have up/down ends, while others have left/right ends. You have to be careful how you orient the cable, because if the bits flow in the wrong direction...well, it's just messy.
"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
|
|
|
|
|
DavidCrow wrote: You have to be careful how you orient the cable, because if the bits flow in the wrong direction...well, it's just messy.
Oh, that's very simple: you've just to be sure it is aligned with the Earth's magnetic field.
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]
|
|
|
|
|
CPallini wrote: Uh, has the cable actually ends?
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
I meant programming way
I know what is inside but how to "learn" program
viliam
|
|
|
|
|
Hello !
So I started having fun with global subclassing. I install a global hook from a DLL and it changes every button's text. It works for every process except for explorer; explorer.exe's buttons aren't changed... Thank you very much as I've been looking a long time for a solution !
<br />
LRESULT CALLBACK MyWndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)<br />
{<br />
if (msg == WM_PAINT)<br />
{<br />
SetWindowText(hWnd,"text");
}<br />
<br />
return(CallWindowProc(pOldWndProc, hWnd, msg, wParam, lParam));<br />
}<br />
<br />
<br />
LRESULT CALLBACK HookProc(int code, WPARAM wParam, LPARAM lParam)<br />
{<br />
return(CallNextHookEx(hHook, code, wParam, lParam));<br />
}<br />
<br />
BOOL APIENTRY DllMain(HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)<br />
{<br />
hMod = (HINSTANCE) hModule; <br />
<br />
if (ul_reason_for_call == DLL_PROCESS_ATTACH)<br />
{<br />
HWND hWnd = CreateWindow("BUTTON","",0, 0, 0, 0, 0,NULL, NULL, hMod, NULL); <br />
pOldWndProc = (WNDPROC)SetClassLong(hWnd,GCL_WNDPROC ,(LONG)MyWndProc);
DestroyWindow(hWnd);<br />
}<br />
return TRUE;<br />
}<br />
<br />
__declspec(dllexport) void DemarrerHook()
{<br />
hHook = SetWindowsHookEx(WH_CALLWNDPROC, HookProc, hMod, 0);<br />
}
|
|
|
|
|
Hi all!
I am doing localization for a software. I've finished most of it except for some MFC default messages. For example:
File / Exit / MessageBox "Save changes in Untitled ?" Yes, No, Cancel
Under English Windows XP, if I run ENG version of my application, the result is fine, which is: "Save changes in Untitled ?". However, when I ran JPN, CHN or KOR version of this, the results were in unknown characters, like a mess.
I haven't tried it under East Asian Windows XP yet, but still, it would be nice it runs normal under English Windows XP. BTW, before localization, I changed this project into UNICODE.
Does anyone know how to solve this?
Thanks in advance!
Joshua
modified on Wednesday, October 29, 2008 12:02 PM
|
|
|
|
|
|
|
It seems that when I host a CListBox in a CDialogBar, in a CMDIChildWnd, whenever I hit the space bar, the selection index goes down one (I'm actually using CCheckListBox but found the behavior exists in the base class CListBox).
I tried handling OnKeyDown, and skipping the call to the base class handler when nChar == VK_SPACE but it still moves the selection index down one when space bar pressed.
When I use the CListBox in a dialog box, pressing the space bar does not move the selection index down.
Can anyone point me in the right direction to suppress the selection index change when pressing the space bar for a CListBox when hosted within a CDialogBar and CMDIChildWnd?
thanks
(Oops, I forgot to mention I'm using VC++ 2003 and I have an app written with VC++ 6.0 that behaves the same way. Also, Windows 2000 and XP have the same behavior)
|
|
|
|
|
Hi,
Currently I had a file type which will be open with a program i created. The file will be open in the normal windows environment by double clicking on the mouse or hitting the enter button.
Is there anyway to get the file name that open the program in the program?
Thanks in advance.
|
|
|
|
|
Yang Jiayi wrote: Is there anyway to get the file name that open the program in the program?
What?
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
|
Do you want to get file name that you clicked on it?
|
|
|
|
|
It should be [somewhere(depends on the open command)] in the CommandLine argument, get the command line arguments from Main function argument or using the API "GetCommandLine". if its MFC Document-View App you can get from CDocument::GetPathName.
|
|
|
|
|
Yang Jiayi wrote: Is there anyway to get the file name that open the program in the program?
Use FindExecutable() .
"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
|
|
|
|
|
Yang Jiayi wrote: Is there anyway to get the file name that open the program in the program?
Yes, the file name that open the program in the program is the program's file name.
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]
|
|
|
|
|
Can someone Please send Me Some Sample code
in VC++ That READS and WRITES data to
STL MAP
Ive Just Gone Through some theory part...
But Dunno How to IMPLEMENT it...
Ive to Store Employee Info Of a COMPANY
USING STL MAP
|
|
|
|
|
Have you at least tried the CodeProject section about STL here[^]?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote "High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
|
|
Hi, first of all I do apologize if the question is already in the message board, but I cannot find it.
Here's my problem.
I've implemented a CDialogBar derived class (it makes common initializations to all the dialog bar I need); then I've derived from it a lot of classes each of which implements a specific dialog (created with the dialog designer); in one of them there are various controls (buttons, static text, list box, ecc.); when I add an event associated with a control (e.g. the OnClick event of a button) the designer creates the corresponding method in the class associated to the dialog. I run the program and the button is disabled.
If I move the entry ON_BN_CLICKED of the CDialogBar derived class' message map into the MainFrm's one, the button is enable, but when the event is fired and the method is called the 'this' pointer within the method points to the MainFrm instance (I would like that the reference is the CDialogBar derived class).
What's wrong?
Thanks in advance for any response.
|
|
|
|
|
Keep the event handler in the CDialogBar[-derived] class itself. To enable the button, you need to handle ON_UPDATE_COMMAND_UI like,
BEGIN_MESSAGE_MAP(CYourDialogBar, CDialogBar)
ON_BN_CLICKED(IDC_BUTTON1, OnButton1)
ON_UPDATE_COMMAND_UI(IDC_BUTTON1, OnUpdateButton1)
END_MESSAGE_MAP()
void CYourDialogBar::OnUpdateButton1(CCmdUI *pCmdUI)
{
pCmdUI->Enable(TRUE);
}
|
|
|
|
|