|
My simple answer is don't do it. The user will want to know which item in the tree is selected, and is likely to be used to the convention used by Explorer.
If you propose using another form of feedback to indicate the selected item, remember that the user has configured colours in the operating system to indicate selected items - it is not necessarily blue (and may not be for a partially sighted user). To get the appropriate colour, use GetSysColor or GetSysColorBrush with the COLOR_HIGHLIGHT argument.
|
|
|
|
|
void CMyView::OnSelchangeMyListBox()
{
m_MyListCtrl.SetCurSel(-1);
}
|
|
|
|
|
I'm using item and subitem editing in all cells in the list control, so either an editbox, combobox or listbox is shown on top of the selected cell.
I'm using "SetItemState" after editing to prevent the blue rectangle from coming up, but every time you click on an item you see the rectangle flashing by. To perfect my app I would like to get rid of even this one, even if you just see it for some milliseconds.
Maybe I'm a pedant, but I'm never satisfied with something until I get it 100%.
|
|
|
|
|
Hi Experts,
I am using MICROSOFT HELP WORKSHOP to develop help for my VC ++ application.
It has gor 3 help files HELP.hlp HELP1.hlp and HELP2.hlp.
And a content file which describes these three files.
The three help files have links to three RTF documents which contain the information.
I donot know how to configure the OPTIONS and MAP.
I am getting error when i try to compile and execute the CONTENTS file and try opening any one of the three help files.
The error is " THE TOPIC DOES NOT EXIST. CONTACT YOUR APPLICATION VENDOR FOR UPDATED HELP FILE".
and even a note while compiling as:
HC1010: Note:
The following mapped Topic IDs were not used in any topic:
IDH_ID.
I am not being able to locate the LOG File.
I have given topic ids for the three help files as IDH_ID, IDH_ID1, IDH_ID2
Please let me know the modifications i need to make.
The Log file info. is as follows.
LOG FILE INFO HELP.hlp::
Microsoft (R) Help Compiler
HCRTF 4.03.0002
Copyright (c) Microsoft Corp 1990 - 1995. All rights reserved.
help.hpj
HC1010: Note:
The following mapped Topic IDs were not used in any topic:
IDH_ID
0 Topics
0 Jumps
0 Keywords
0 Bitmaps
Created D:\CREATE HELP\HELP WRK SHOP\Project\Help.hlp, 3,823 bytes
Compile time: 0 minutes, 0 seconds
1 note, 0 warnings
LOG FILE FOR CONTENTS.CNT::
Creating the help file Help.hlp.
Processing D:\CREATE HELP\HELP WRK SHOP\Project\TOPIC.rtf
HC1010: Note:
The following mapped Topic IDs were not used in any topic:
IDH_CATALOGUE
Resolving keywords...
Adding bitmaps...
0 Topics
0 Jumps
0 Keywords
0 Bitmaps
Created D:\CREATE HELP\HELP WRK SHOP\Project\Help.hlp, 3,823 bytes
Compile time: 0 minutes, 0 seconds
1 note, 0 warnings
KINDLY LET ME KNOW THE PROCEDURE AND FORMAT FOR SETTING THE TOPIC IDs.
Regards
Ram
|
|
|
|
|
The RTF files in your project can have many individual topics present in them. A typical one would look like:
${\footnote The title of the topic}
K{\footnote Topic keywords1; Topic keywords2; ...; ...}
#{\footnote HIDD_OF_DIALOG}
{\b Topic title}\line
\line
Topic text\line
\page
When you compile your help file, HelpWorkshop makes use of the YourAppName.hm file, which contains all the topics ID's. This is generated from your apps resource.h file by running the MakeHelp.Bat file, which can be found in your applications main source file directory.
To create a help topic, add a topic entry like above with the correct topic ID, typically HIDD_DIALOG_ID for example, to one of your .rtf files. Then once compiled, you can copy your .hlp file to the application directory and test it. Use helpworkshop to monitor which help messages are being requested. Use the option View\WinHelp messages<\b>
This is a brief overview. Hopefully, will be of some help.
Roger Allen
Sonork 100.10016
Were you different as a kid? Did you ever say "Ooohhh, shiny red" even once? - Paul Watson 11-February-2003
|
|
|
|
|
This code keeps on tripping the sendto(); failed if statement. I can't figure this out. Any help is much appreciated.
Thank you.
void CSSPingDlg::OnPing()
{
// TODO: Add your control notification handler code here
CIPAddressCtrl *ipaddressctrl = (CIPAddressCtrl *) GetDlgItem(IDC_IPADDRESS);
CEdit *editbox = (CEdit *) GetDlgItem(IDC_EDIT);
byte field1,field2,field3,field4;
char ipchar[100];
DWORD dip;
WSADATA wsaData;
SOCKET sock;
static ECHOREQUEST echo_req;
struct sockaddr_in sin;
ipaddressctrl->GetAddress(field1,field2,field3,field4);
sprintf(ipchar, "%d.%d.%d.%d",field1, field2, field3, field4);
dip = inet_addr(ipchar);
if (WSAStartup(MAKEWORD(2,2), &wsaData) != 0)
{
AfxMessageBox("WSAStartup failure!",MB_OK);
}
if ((sock = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)) == SOCKET_ERROR)
{
AfxMessageBox("Error starting socket",MB_OK);
}
sin.sin_family = AF_INET;
sin.sin_port = htons(0);
sin.sin_addr.s_addr = dip;
echo_req.icmpHdr.icmp_type = ICMP_ECHOREQ;
echo_req.icmpHdr.icmp_code = 0;
echo_req.icmpHdr.icmp_cksum = 0;
echo_req.icmpHdr.icmp_id = 1;
echo_req.icmpHdr.icmp_seq = 1;
memset(echo_req.cData, ' ', REQ_DATASIZE);
echo_req.icmpHdr.icmp_cksum = checksum((unsigned short *)&echo_req, sizeof(ECHOREQUEST));
if (sendto(sock, (const char *) &echo_req, sizeof(ECHOREQUEST), 0, (SOCKADDR *) dip, sizeof(SOCKADDR_IN)) == SOCKET_ERROR)
{
AfxMessageBox("sendto() failed: %d\n", MB_OK);
}
closesocket(sock);
WSACleanup();
}
|
|
|
|
|
I haven't played with raw sockets or icmp but on a quick scan of your code the use of (SOCKADDR*)dip in the sendto fn looks wrong - don't you mean to use (SOCKADDR*)sin instead?
Phil
|
|
|
|
|
there is an application through which I generate some data, and while printing I want to get the printout in PDF format(I have the PDF writer with me), in that what I get is that the browser window asks me first to save the file in a different format which I don't want. I just want file to be stored at some specified location(which we are free to decide)....In all I want that once the user gives the print command he should get the printout in the PDF format....no interaction in between.....there are some .dlb files which we can access and to save the data.....but the problem is that we will have two instances one which was created when you sent the print command and the second one which we create......so is it possible to automate the whole thing..
regards
Maverick
|
|
|
|
|
I want to draw a line with mouse using CDC::LineTo(m_point).But when I move mouse,the line is drawn repeatedly.I know I must set CDC's bkmode.But I don't know how to set.If you tell me,I'll thank you very much.
For my english is poor,if you can't get my mean,please tell me.
My goal is to exceed Bill Gates.
|
|
|
|
|
SetROP2(R2_XORPEN) and don't forget to redraw the old line before drawing the next one.
--
-Blake (com/bcdev/blake)
|
|
|
|
|
Hi.
I do so.The color of the line I drawn is changed.But the line didn't dispear.Why?
|
|
|
|
|
That's the second part of what I wrote earlier. You have to remember the coordinates to which you last drew the line. Then on a mouse move you redraw it again at the old location to erase it and draw it at the new location.
--
-Blake (com/bcdev/blake)
|
|
|
|
|
I know the principle of the procedure.I use the SetRop2() function to realize it.But which parameter should I select? R2_NOT? Or R2_XORPEN?Almost all parameter I had test.None looks like correct.
And I've another question.I wrote message processed module associate to mousemove to draw line.But when the window is restore from behind other window,the line dispeared.Why?How can I resolve it?
Please help me!If you resolve my question,I can buy some gift for you if you want.;)
|
|
|
|
|
R2_NOT will work, it simply inverts the background pixels and ignores the pen.
R2_XORPEN will work better, as it lets you controlly the visual result better, using a dashed pen for example.
If it isn't looking correct I suspect you are not redrawing over the previous line exactly.
Things you draw during mousemove are not permanent. Your application needs to redraw everything, including the newly added line, when handling WM_PAINT as well.
--
-Blake (com/bcdev/blake)
|
|
|
|
|
I have laboriously coded around this little problem for years and I know that the solution is quite simple. But I am resistant to change and hate having to delve into documentation.
I am getting that "class already defined" error message when I include the same header file in more than 1 source file.
Here is what is happening:
ClassX - a user defined class
Window1 - the apps main window
Window2 - a modal dialog box invoked from Window1
Window1 has an instance of ClassX and so has "#include ClassX.h" in its header file (and won't compile without it of course)
Window2 has an instance of ClassX and so needs to "#include ClassX.h" in its header file
But it can't because it throws that error "C2011: 'ClassX' : 'class' type redefinition" error
Why is it that you can include headers like "afxdb.h" in a zillion files and not get this error?
If the compiler knows that the class is already defined, then why does it need the header file in both places?
|
|
|
|
|
Terry O`Nolley wrote:
Window1 has an instance of ClassX and so has "#include ClassX.h" in its header file (and won't compile without it of course)
Window2 has an instance of ClassX and so needs to "#include ClassX.h" in its header file
Declare the ClassX header file in Window1's and Window2's cpp files and not in the h files. make sure you include this header *before* you include te header file for Window1/Window2. So Window1.cpp would ne :-
include classx header
include window2 header
include window1 header
...
and window2.cpp wopuld be :-
include classx header
include window2 header
...
Regards
Nish
Extending MFC Applications with the .NET Framework [NW] (coming soon...)
Summer Love and Some more Cricket [NW] (My first novel)
Shog's review of SLASMC [NW]
Come with me if you want to live
|
|
|
|
|
Thanks Nish.
This brings me to a problem though - since Window2 needs a member variable of ClassX (because that member variable will be filled in by Window1 after instantiating Window2 but before calling DoModal()) doesn't the #include ClassX.h need to go before the class definition for Window2?
|
|
|
|
|
|
How would you resolve the issue I was having without using preprocessor directives?
I seemed to have been caught in a Catch-22.
WHen I followed your example, it didn't give an error relating to duplicate class definitions, but I got errors for an undefined keyword (ClassX) because the ClassX header wasn't included until after I tried to define an object of ClassX.
|
|
|
|
|
|
I know this. But your first suggestion told me to include the header file in the .cppp file for Window 2 to avoid the "duplicate class name" error. I couldn't do this, because there was a member variable of tyoe ClassX in Window2.
When presented with the preprocessor directives, I implemented them and it fixed the problem but you said this was not a preferred technique because of portability concerns.
How would you do this without preprocessor directives?
ClassX
Window1 : has a member var of ClassX so needs #include ClassX.h
Window2 : has a member var of ClassX so needs #include ClassX.h
if I include them both where you have agreed they need to be ie before the ClassX object is defined I get a compiler error of a duplicate class name.
If I include them where you first told me (in the CPP file before the window header) I get an undefined name error.
Using preprocessor directives allowed me to successfully do what I needed but you said it was a poor solution.
I would like to know the correct solution.
|
|
|
|
|
You need include guards in your header files:
#ifndef CLASSX_H_INCLUDED
#define CLASSX_H_INCLUDED
#endif // ndef CLASSX_H_INCLUDED There is also #pragma once but I prefer the above way since you can test for whether ClassX.h has been included with #ifdef CLASSX_H_INCLUDED
--Mike--
Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber
CP SearchBar v2.0.2 released
|
|
|
|
|
Thanks Mike - that did the trick.
I had used those a while back without remembering why I used them
And I never noticed when I stopped using them.
I guess it took a big screeching halt to make me remember to always use them.
|
|
|
|
|
I take things a bit farther. Here is what I do :
#ifndef _HEADER_H
#define _HEADER_H
#else
#error repeated include of this file
#endif
then if this header must be included in another header file (nested) I do this -
#ifndef _HEADER_H
#include header.h
#endif
I went through and converted a rather large project to this scheme and my compile times decreased considerably. If you use a standard macro naming mechanism (_HEADER_H for me) then this is quite easy to use.
The Ten Commandments For C Programmers
|
|
|
|
|
Rick York wrote:
#ifndef _HEADER_H
#include header.h
#endif
I used this technique for a while and then I realized that the increased code clutter (three lines/include vs just one) wasn't worth the extra milliseconds saved per compiled unit. Instead, I made sure to use a precompiled header which really sped things up.
Regards,
Alvaro
Hey! It compiles! Ship it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
