|
It is a pseudo-code?
Could you instead post a compilable and properly formatted code snippet?
Or, at least, explain what errors or other problems you have with this code?
|
|
|
|
|
 no it is not a pseudo code am trying to write a program that can register a contact, delete or update the contact. so when i compile the is an error message "invalid array assignment" within the the delete function which is the code i posted before. the complete code is
<pre>#include<iostream>
#include<conio.h>
#include<string.h>
#include<fstream>
using namespace std;
enum type{ home,work,fax,mobile,other };
struct contact{
char num[15];
char name[20];
char TphoneN[6];
}phone[5];
const int max=5;
int index=0;
bool reading(){
char v;
if(index<=5){
cout<<"please enter phone number: ";
gets(phone[index].num);
cout<<"please enter the name: ";
gets(phone[index].name);
cout<<"the type of number( fax, mobile, home, work, other): ";
gets(phone[index].TphoneN);
index++;
return true;
}
else
return false;
}
bool delet(){
int flag=0;
cout<<"please enter the name of the person u wanna delete: ";
char del[20];
cin.getline(del,20);
for(int i=0; i<=index; ++i){
if(phone[i].name==del){
for(int j=i; j<=index; ++j){
phone[j].num=phone[j+1].num;
phone[j].TphoneN=phone[j+1].TphoneN;
phone[j].name=phone[j+1].name;
}
flag=1;
}
}
if(!flag){
return false;
}
else{
index--;
return true;
}
}
void all(){
for(int i=0; i<=index; ++i){
cout<<phone[i].name<<"\t"<<phone[i].num<<"\t"<<phone[i].TphoneN<<endl;
cout<<"\n";
}
}
int main(){
int x;
while(!0){
cout<<"****"<<index<<"contact entries **** \n";
cout<<"0 end \n1 new contact \n2 delete contact \n3 all contact \n4 empty contact memory";
cin>>x;
switch(x){
case 1:
bool y=reading();
if(y==true){
cout<<"contact successfuly saved";
}
else
cout<<"an error accure could not save your contact";
break;
case 2:
bool y=delet();
if(y==true){
cout<<"contact successfuly deleted";
}
else
cout<<"sorry your name does not exist";
break;
case 3:
all();
break;
case 4:
cout<<"still searching";
break;
default:
cout<<"sorry invalid key";
break;
}
}
}
|
|
|
|
|
If you are using C++ then a std::string is better option than an array of characters.
|
|
|
|
|
Hello Everyone, I have some doubt regarding below code snippet.
MyDlg::MyDlg(CWnd* pParent )
: CDialogEx(IDD_DLG, pParent)
, m_Name(_T(""))
, m_Status(_T(""))
, m_Comments(_T(""))
{
}
Please explain why m_Name(_T("")),m_Status(_T("")),m_Comments(_T("")) is there.
Thank you.
I'm new to MFC VC++.
|
|
|
|
|
What you see here is a member initialization list
It is (almost) equivalent to initialization within a ctor like:
MyDlg::MyDlg(CWnd* pParent /=NULL/)
: CDialogEx(IDD_DLG, pParent)
{
m_Name = _T("");
m_Status = _T("");
m_Comments = _T("");
}
|
|
|
|
|
Thank you. That clear my doubt
If you don't mind could you explain this line too:
CHeaderCtrl* pHeader = (CHeaderCtrl*)m_ListControl.GetDlgItem(0);
|
|
|
|
|
Where did you get this code?
The better way to obtain the pointer to a header control is using CListCtrl::GetHeaderCtrl method.
|
|
|
|
|
Thanks for the reply.
I got this code snippet from an MFC tutorial website.
void CMyDlg::ResetListControl() {
m_ListControl.DeleteAllItems();
int iNbrOfColumns;
CHeaderCtrl* pHeader = (CHeaderCtrl*)m_ListControl.GetDlgItem(0);
if (pHeader) {
iNbrOfColumns = pHeader->GetItemCount();
}
for (int i = iNbrOfColumns; i >= 0; i--) {
m_ListControl.DeleteColumn(i);
}
}
I know this code will reset all the Item and column in the list view control.
I want to get a deeper understanding in that specific line of code.
|
|
|
|
|
Well, perhaps it is still working, but is there any guaranty it will also work in every new Windows version? What will happen if header control will get some other control ID?
|
|
|
|
|
|
Thank you.
BOOL CMyDlg::OnInitDialog()
{
CDialogEx::OnInitDialog();
..........
..........
return TRUE;
}
What is the reason of calling the base class member function
CDialogEx::OnInitDialog() inside the child class member function?
BOOL CMyDlg::OnInitDialog()
|
|
|
|
|
All the dialog controls are created and subclassed within the base class CDialogEx::OnInitDialog()
|
|
|
|
|
|
First of all Thank you for the help.
Is this concept similar for CWinApp::InitInstance . Even when I commented this line my application still works. why?
BOOL CWindowApp::InitInstance()
{
CWinApp::InitInstance();
CMyDlg dlg;
m_pMainWnd = &dlg;
INT_PTR nResponse = dlg.DoModal();
.......
.......
.......
}
I would like to ask one more question regarding m_pMainWnd. Sorry if this is a silly question. Why do we assign the address of the dialog to m_pMainWnd?
I know m_pMainWnd is a CWnd* m_pMainWnd.
|
|
|
|
|
Quote: Is this concept similar for CWinApp::InitInstance . Even when I commented this line my application still works. why?
There are two alternative explanations:
- The
CWinApp::InitInstance does nothing, so it is safe to discard its call. InitInstance does perform some initialization that now is missing in your application. Your application may run fine, at the moment, (for instance because it doesn't need such initializations) but this is definitely not a safe scenario.
Bottom line: if they (Microsoft) do invoke CWinApp::InitInstance in their code samples (and in generated code) then I would do the same.
Quote: hy do we assign the address of the dialog to m_pMainWnd?
I know m_pMainWnd is a CWnd* m_pMainWnd. Possibly because the dialog it is the application main window.
|
|
|
|
|
Note that if these m_Name, m_Status, m_Comments are CString (CStringA, CStringW, CStringT) objects then you do not need to additionally initialize them to empty because they are already created (via default ctor) as empty strings.
|
|
|
|
|
True, but I expect that in this case the compiler will optimze away the double initialization. All that remains is a little bit of extra code that, while not needed, serves to clarify that these members are indeed properly initialized - no matter what types these members really are.
Moreover, if the types happen to change in the future, it's safer not to rely on them being initialized by default.
It's similar to soem C++ keywords, like override : at the time you add it to your code, it doesn't serve any purpose but documentation. But if the virtual base method gets changed in the future, it's safer to use the override keyword because then the compiler will complain if you don't also adapt your override method(s).
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Hi
I have a c DLL. the Dllmain and the exported function(s) are in different source files. Since the exported function need the value of the variable dwTlsindex. I decalre as an extern
I both define it and declare it in DllMain
extern DWORD dwTlsIndex;
static DWORD dwTlsIndex;
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
in the exported function the following is the definition I know I have used the extern storage specifier with out any problem many times maybe there is something different because this is a DLL as the linker cant resolve dwTlsIndex
#else
__declspec(dllexport) void opendata(char *);
#endif
extern DWORD dwTlsIndex;
void opendata(char *filename)
{
typedef void *(DLL_FN)(char *);
|
|
|
|
|
Quote: extern DWORD dwTlsIndex;
static DWORD dwTlsIndex;
You should just write
DWORD dwTlsIndex;
because:
- You don't need the extern declaration in the file that defines the variable.
- The
static keyword makes the variable having file-scope (link failure).
|
|
|
|
|
Tried it still getting unresolved maybe something I have to do in my project
|
|
|
|
|
|
I'm working on a program that needs to be able to detect when the user has clicked on a font glyph - the actual filled part of the glyph, not just its bounding box. I'm trying to do this by analyzing the outline produced by GetGlyphOutlineW for each glyph. In this program, most glyphs are drawn by passing a single codepoint to TextOutW, but there is one case where I pass multiple codepoints. I understand that in this case, I have to take kerning into account in order for my analysis of the glyph outlines to match up with what TextOutW draws. Keeping in mind that I want to stick to C API's since the program is actually in another language and calling winAPI through a foreign function interface, are the GetKerningPairs functions the only way to get the necessary information to account for the kerning? In particular, do I have to iterate through all the kerning pairs for the entire font and check each one for whether it matches the pair I'm trying to kern rather than, say, asking Windows for the kerning pair for a particular pair of characters, if one exists?
|
|
|
|
|
Hi
I have the same piece of code running on Windows and Zos (mainframe) is it possible to typedef the read
I am getting a compile error saying before SYSREAD there should be a ";"
thanks
I.e.
#ifdef ZOS
size_t fread(void * __restrict__buffer, size_t size, size_t count, FILE * __restrict__stream) SYSREAD;
#ELSE
typedef BOOL ReadFileEx(HANDLE, LPVOID, DWORD, LPOVERLAPPED, LPOVERLAPPED_COMPLETION_ROUTINE) SYSREAD;
#endif
HANDLE hFile;
|
|
|
|
|
That's not a valid typedef, and you cannot resolve your problem in this manner. You could create a typedef for a function that takes a certain list of parameters, and returns BOOL, but that would not then be tied to the function ReadFileEx as appears to be your intent.
(and, on a sidenote, I'm not sure the compiler will eat that capitalized #ELSE)
Just provide an adapter function for this purpose:
#ifdef ZOS
...
#else
BOOL SYSREAD(...)
{
return ReadFileEx(...);
}
#endif
P.S.: NOw that I've reread the code you've written, I am no longer sure what it's supposed to do. I still think that an adapter function is what you need, but the syntax you've used above doesn't appear to make any sense under that assumption.
So, if you intended something else, maybe you should point out what that code should do, or better yet, show a line of code or two that uses SYSREAD in the intended manner.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|