C / C++ / MFC

Error when use IDiskQuotaUser interface.

19-Sep-02 10:20

You can with DDX/DDV. Take a look in your docs at UpdateData and related stuff.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Anonymous19-Sep-02 9:56

Anonymous

19-Sep-02 9:56

Hi all,
When I use IDiskQuotaUser->SetQuotaLimit() and ->SetQuotaThreadshold()there are always pop up an error dialog: like this:
//////////////////////////
Dubug Error
Program:**
Modlue:
File:i386\chkesp.c
Line 42
The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.

Why?????????????????????????????????????

And How to resove this problem?

I tried to use static dll to build the project but failed for LNK2005 error.
also can not resolve the problem.

Thanks for help.
Dead | X|

Re: Error when use IDiskQuotaUser interface.

Lakitu19-Sep-02 23:32

Lakitu

19-Sep-02 23:32

chkesp errors usually have their origins in passing around malicious pointers and/or wrong parameter sizes and counts. In this case it could be the LONGLONG value that's used in those calls. Happened to me once. OMG | :OMG:

T2W

ns19-Sep-02 9:29

19-Sep-02 9:29

In code that I have, theres a T2W. MSDN and the web are not helpful.

 char* strFile = new char[strFile0.GetLength() +1];

strcpy(strFile, strFile0);

_bstr_t b_strFile = T2W(strFile);

What exactly does T2W do?

Thanks,
ns

Joaquín M López Muñoz19-Sep-02 9:40

19-Sep-02 9:40

T2W converts from TCHAR strings to Unicode strings. Next obvious question is, what are TCHARs? Well, TCHAR is a macro resolving either to char or wchar_t (Unicode character), depending on whether your app is being build in ANSI or Unicode mode. If in Unicode mode, T2W converts from Unicode to Unicode, i.e, it does nothing, but this apparent futility have some sense if you consider that this way the same source code can compile fine in either mode.
In your particular case, your source string is ANSI (char *), which has the following implications:

This will only work in ANSI mode (in Unimode, T2W will accept only Unimode strings).
Taking into account the former, you could have used A2W (ANSI to Unicode) instead

So, I'd label this as a small flaw in the code. You'de be better off using TCHAR * as the type of strFile if pursuing Unicode compatibility.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

ns19-Sep-02 9:59

19-Sep-02 9:59

I dont know how relevant this is, but this all started because I had to pass a CString (coming from GetWindowText) or char* into a VB com dll which had a parameter of type String. T2W fixes that. Should I replace it with A2W. I'm asking because I dont know about setting the mode in VC. I didnt even know I had a choice! Where in the IDE do I set the mode? Also whats the purpose of these two different modes - is it like one runs on Unix and one on windows or something? From your post the default mode my app is being built in must be ANSI. So can you please let me know where the mode setting is (I looked in some obvious places), and why a mode is chosen. Does A2W mean it will work in both modes?

Thanks,
ns

Joaquín M López Muñoz19-Sep-02 10:19

19-Sep-02 10:19

Well, writing code that compiles in both modes is a tedious task (specially when you didn't planned for it before) and IMHO it is not worth the effort if you don't really need it (which seems your case). If you renounce to compile in Unicode mode, then A2W and T2W are the same, but at least with A2W you are making it splicit that the code is intended for ANSI mode only.
To build your app in Unicode mode, go the project settings and define preprocessor macros UNICODE and _UNICODE. Although you might be able to succesfully build your project please be aware that Windows 9x OSs are not Unicode compliant, so the app won't just run (in Windows NT/2k/XP it should).
The difference between ANSI and Unicode modes is that the OS APIs you call are different in either mode, accepting char * or wchar_t * strings (for APIs not dealing with text, as for instance GetMessage there's no difference). Unicode is intended for apps in exotic languages, having often more characters than a single char can accommodate.

Apart from this, I think you can simplify your code a little:

USES_CONVERSION;
LPCOLESTR lpcostr=A2COLE((LPCSTR)fileString);
//call the VB DLL using lpcostr

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Dbl Click in control - DateTimePicker

ns19-Sep-02 10:25

19-Sep-02 10:25

Thanks for the explanation. I think I'll stay ANSI for now. Smile | :)

Thanks,
ns

john john mackey19-Sep-02 9:07

john john mackey

19-Sep-02 9:07

Hi.

I want to recognize a double click (right mouse button) in a DateTimePicker control, but don't know how to or aware of scenarios that might cause a problem with this.

What I have is grid of edit-able controls (CEdit, CDateTimePicker, CComboBox) and for a Date Time Picker, I want a double-click to capture the current time.

This is to help data entry by the user.

Any help/suggestions?

Thanks.
Johnny Pino

Re: Dbl Click in control - DateTimePicker

john john mackey19-Sep-02 9:08

john john mackey

19-Sep-02 9:08

Sorry, I meant LEFT MOUSE BUTTON (double click), but either left/right should work.

JP

OnInitDialog question

ns19-Sep-02 9:02

19-Sep-02 9:02

I have a CDialog derived class I want to use in two places, which differe in functionality. If I set a flag from the spawning

view class (which does a DoModal()), is it allowed to set a flag that will make OnInitDialog behave differently?

BOOL abc = TRUE;

myDlg.SetFlag(  abc) //which sets a member of the CDialog class.

myDlg.DoModal();

and in the CDialog class, :

::OnInitDialog()
{
if (m_flag)
    {

        dosomething;
     }
else
    {
      dosomethingelse;
    }

Is this allowed? I cant really write two different OnInitDialogs, right? So in order to reuse it I am thinking of my flag idea.
Suggestions?

Thanks,
ns

TyMatthews19-Sep-02 9:28

19-Sep-02 9:28

Yes, you've got it right. Personally, I would make an enumeration variable in the dialog class and use that as the flag. That way, you can switch() on the flag and support future enhancements when you want more than two different behaviors. Just as soon as you've written all the code for two modes you'll find that you now want to have three Smile | :)

The additional effort involved is very little.

<code>
class CMyDlg : public CDialog
{
public:
    typedef enum
    {
        Mode1,
        Mode2,
        Mode3
    } MyDlgModes;
 
private:
    MyDlgModes m_Mode;
 
public:
    SetDlgMode( MyDlgModes Mode )
    {
        m_Mode = Mode;
    }
};
 
BOOL CMyDlg::OnInitDialog()
{
   switch( m_Mode )
   {
   case Mode1:
       ... do stuff
   case Mode2:
       ... etc
   
   }
}
 
MyFunc()
{
    CMyDlg dlg;
    dlg.SetDlgMode( CMyDlg::MyDlgModes::Mode1 );
    dlg.DoModal();    
}

"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." -Albert Einstein

ns19-Sep-02 9:37

19-Sep-02 9:37

Once again, a million thanks for your patiently detailed resolution. It helps tremendously! I thought I'd have to define the enum globally (can this even be done? like an extern enum)so using the enum declared in CMyDlg is pretty tricky! Appreciate your responses very much indeed!
Big Grin | :-D

Thanks,
ns

TyMatthews19-Sep-02 9:58

19-Sep-02 9:58

Hey no problem at all. It's fun to help out people. You can define the enum globally, although it is cleaner and more "object oriented" to only put the enums in the classes that actually need and use them. That said, if you want to use those same enum values all over the place in other unrelated classes, that's when you'd want to think about defining it in the global scope and putting it in some header. So long as your enum variables aren't global, a global enum typedef won't displease the OO fanatics out there Smile | :)

"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." -Albert Einstein

ns20-Sep-02 11:25

20-Sep-02 11:25

I did:

case Mode1:

	int index = 0;

	KeyValueMap & keyValueMap = *m_kVMap;

	KeyValueMap::iterator it = 	keyValueMap.begin();

	for(; it != keyValueMap.end(); it++)
	{
		m_listAddRecord.InsertItem(index, (*it).first);

		index++;
	}

//	KeyValueMap::iterator it1 = keyValueMap.begin();

	CString temp = m_listAddRecord.GetItemText(0,0);

	m_editAddedKW.SetWindowText(temp);

	m_editAddedVal.SetWindowText("");
	m_editAddedVal.SetFocus();

//	m_Dismiss.EnableWindow(FALSE);

	m_DoneAdd.EnableWindow(TRUE);

        case Mode2: //left it blank for the moment.

The compiler errors said I was skipping initialization of "temp" and "it" with the case statement. Do I need a return or something somewhere?
I'm doing it with if m_Mode == Mode1 but yours was so cool...
Any idea what its not happy about and how to fix it?

Thanks,
ns

TyMatthews20-Sep-02 12:41

20-Sep-02 12:41

Yeah... with a case statement it is possible to jump over code that would otherwise be executed. It's almost like a goto statement. For instance, when case is Mode1, you're going to execute all of the code up to where Mode2 starts. What happens if you don't put a break in there, like you've got in your sample? Well in C++, unlike VB, you keep executing right through to the next case statement. This is one of those classic "gotcha" bugs. This by itself is not an error, however, because it is perfectly legal to want to keep executing the code in the next case section.

Someone doing this "case fall through" scenario on purpose might be thinking they can keep using the variables they declared in the previous case block for Mode1. Which might be true if you always executed the code for case Mode1. But you're not guaranteed that, since you might come in directly at case Mode2. Mode2 skips all of those variable declarations and initializations. Your variables don't exist there, so they can't be used nor referenced in that scope. This is a paradox between otherwise legal code and its run-time handling. As such, you have to give another layer of scope to declare any variables inside a case section. Here's some sample code:

std::vector< int > OuterVector;
 
switch( i )
{
  std::vector< int > SwitchVector;
 
  case 1:
  {   
      std::vector< int > InnerVector;
      std::vector< int >::iterator itInnerVector;
  }
 
  // fall through on purpose
  case 2:
  {
      // I can't access InnerVector or anything else declared in case 1.
      // I can access OuterVector, because it was declared outside of this scope
      // and is guaranteed to be initialized
  }
  break;  
}

As you can see, I've added some block braces {} around the code for both case 1 and 2. This defines a new scope for those variables declared inside the block. They can only be used within that scope since they will be destroyed as soon as execution leaves that scope. If you tried to reference those variables in case 2, you'd get a compiler error because they don't exist.

If indeed you wanted to use the same variables in both case Mode1 and Mode2 when you fell through on purpose, you'd have to declare those variables either before the switch statement, as I've done above with OuterVector, or immediately after the switch but before any case statements are specified, as you see with SwitchVector. The former is a little clearer for other people to understand, but there might be scope issues that require the switch-level scope of the latter.

So, the long story short: wrap your case sections with curly braces. This should help to understand why it is considered an error, however. I've become so accustomed to adding braces to case blocks that I don't even think twice about it when they come out of my fingertips automatically. Here's your sample code tweaked a little bit:

case Mode1:
{
    int index = 0;
    KeyValueMap & keyValueMap = *m_kVMap;
    KeyValueMap::iterator it = 	keyValueMap.begin();
    for(; it != keyValueMap.end(); it++)
    {
        m_listAddRecord.InsertItem(index, (*it).first);
        index++;
    }
    // KeyValueMap::iterator it1 = keyValueMap.begin();
    CString temp = m_listAddRecord.GetItemText(0,0);
    m_editAddedKW.SetWindowText(temp);
    m_editAddedVal.SetWindowText("");
    m_editAddedVal.SetFocus();
    // m_Dismiss.EnableWindow(FALSE);
    m_DoneAdd.EnableWindow(TRUE);
}
break;
 
case Mode2: //left it blank for the moment.

I'm guessing from your previous posts that you don't really want to fall through from case Mode1 to Mode2. So remember to add that break statement before the case Mode2 code starts. That's one key difference between the VB syntax and VC Smile | :)

"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." -Albert Einstein

Wow! Thanks!!!

ns20-Sep-02 12:53

20-Sep-02 12:53

What a truly excellent explanation. Thank you so much. Indeed I need the 'break'. Have a good weekend!

Thanks,
ns

Re: Wow! Thanks!!!

TyMatthews20-Sep-02 13:05

20-Sep-02 13:05

You bet, have a good weekend too!

"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." -Albert Einstein

Joaquín M López Muñoz19-Sep-02 9:30

parent IShellFolder on windows 98

19-Sep-02 9:30

This is perfectly valid and most usual, particularly if differences are not wild (i.e. if you're not forced to check for m_flag in every handler).

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

luc219-Sep-02 8:24

luc2

19-Sep-02 8:24

hello,

i'd like to get the parent IShellFolder, but i don't want to use the SHBindToParent function because i want my program to work on windows 98.

how can i do that ?

Re: parent IShellFolder on windows 98

Joaquín M López Muñoz19-Sep-02 9:48