C / C++ / MFC

Dbl Click in control - DateTimePicker

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

Re: T2W

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

Re: parent IShellFolder on windows 98

19-Sep-02 9:48

Vassili Bourdo's ITEMIDLIST management library
[^] provides a replacement of the function for Windows 9x/NT.

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

luc219-Sep-02 23:27

luc2

19-Sep-02 23:27

thanks very much my friend

_int64 store / restore problem

Anonymous19-Sep-02 8:20

Anonymous

19-Sep-02 8:20

I used the defines :

<br />
#typedef unsigned hyper ulonglong;<br />
<br />
#define uint8korr(A)	(*((ulonglong *) (A)))<br />
#define int8store(T,A)	*((ulonglong *) (T))= (ulonglong) (A)<br />

In my code, pbuf is a PBYTE pointed to
1 e1 f5 5 0 0 0 0

When I want to store the data into another buffer pdata, I did:

int8store(pdata, pbuf);

I got the dump of pdata becomes:
e0 2e 35 1 0 0 0 0

Anything wrong ??? It seems it's just doing casting and then setting A = B stuff. Why did the value has changed ?

Re: _int64 store / restore problem

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

How to pass a CList to another function?

19-Sep-02 9:27

#define int8store(T,A) *((ulonglong*)(T))=(ulonglong)(*(A))

(I think)

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

John Wong19-Sep-02 8:15

John Wong

19-Sep-02 8:15

Need help from guru!

I need to pass a CList to another function.
When I just pass to CList* plist = &pTeacher;
it doesn't work! please help! Confused | :confused:

my Clist is like this,

CList<cteacher, cteacher=""> pTeacher;
// CTEACHER is a structure.

Thank for attention!
JW

Re: How to pass a CList to another function?

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