Mobile

19-Jun-03 8:56

I have a CPropertySheet-derived class (with no associated dialog template). In the constructor, I call AddPage() for the three CPropertyPage-derived classes (Thin/Child templates).

I've tried a number of things, but I can't seem to get any of the propertysheet buttons displayed.

What am I missing?

------- signature starts

"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001

Please review the Legal Disclaimer in my bio.

------- signature ends

João Paulo Figueira19-Jun-03 9:31

19-Jun-03 9:31

Hi, John! Nice to see you back on the forum.

John Simmons / outlaw programmer wrote:
I've tried a number of things, but I can't seem to get any of the propertysheet buttons displayed.

To what buttons are you referring? Are these from your dialog template?

#realJSOP19-Jun-03 9:53

19-Jun-03 9:53

João Paulo Figueira wrote:
Hi, John! Nice to see you back on the forum.

I've always been here. Smile | :)

Recently, I've been converting code from other projects to work in our PPC2K project. We have a common code base that is shared between apps that run on the Windows desktop, and apps that run on CE 2.12 proprietary embedded devices that don't have a (Windows) user interface. The problem has been that some of the compiler definitions are defined in such a way as to assume that if the program is being written for CE, then there is no user interface (not true for our PPC2K project), or that if MFC is being used, it must be a desktop Windows project (again, not true in our current case).

Needless to say, this project has turned out to be the very bane of my miserable existance. Add to that, we're shoe-horning STL into the project, there's just plain strange legacy code, and my total lack of familiarity with the idea behind what I'm working on, and you can probably guess that I've been fairly hard to live with recently.

Anyway, I'm temporarily working on some of the interface stuff once again.

João Paulo Figueira wrote:
To what buttons are you referring? Are these from your dialog template?

You know, the buttons that always show up on a propertysheet under VC6, especially when you don't need them - Okay, Cancel, and Apply (and I don't need apply, but I do need cancel). I've even gone back to the basics of using property sheets to see where I could have gone wrong, and I can't see anything wrong with what I've done.

------- signature starts

"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001

Please review the Legal Disclaimer in my bio.

------- signature ends

João Paulo Figueira19-Jun-03 22:31

19-Jun-03 22:31

John Simmons / outlaw programmer wrote:
Okay, Cancel, and Apply

As far as I know the Pocket PC 2002, you only get the top left-hand-corner ok button. I'm not sure about the Pocket PC 2000, but I've seen dialogs with both the ok and the close (X) box. By using this button you would effectively cancel the dialog.

I've recently came up with a solution, although it is not a standard one: insert a command bar in the dialog / property sheet and place the ok and cancel buttons there (graphic buttons). To do this, have a look at these articles:

A File Open Dialog for the PocketPC 2002[^]
Property sheet callbacks in the Pocket PC 2002[^]

The first shows how to put ok and cancel buttons on the dialog's command bar, and the second shows how to put a command bar in a property sheet.

Hope these help.

#realJSOP20-Jun-03 0:30

20-Jun-03 0:30

Thanks I'll look at those.

------- signature starts

"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001

Please review the Legal Disclaimer in my bio.

------- signature ends

#realJSOP20-Jun-03 4:51

20-Jun-03 4:51

The callback article is cool, and I used the concept in our code.

In fact, I think the commandbar thing is a better solution than putting the "OK" and "Cancel" buttons in the titlebar at the top of the screen. However, I'd like to remove the "OK" button from the titlebar if it's possible.

Got any ideas?

------- signature starts

"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001

Please review the Legal Disclaimer in my bio.

------- signature ends

João Paulo Figueira20-Jun-03 5:23

20-Jun-03 5:23

Use this:

//
// Hide the OK button
//
ModifyStyle(0, WS_NONAVDONEBUTTON, SWP_NOSIZE); 
SHDoneButton(m_hWnd, SHDB_HIDE);

This can go in the OnInitDialog of your CPropertySheet.

#realJSOP20-Jun-03 5:35

20-Jun-03 5:35

Perfect! Thanks!

------- signature starts

"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001

Please review the Legal Disclaimer in my bio.

------- signature ends

STL string problem

Jose M Castellanos19-Jun-03 0:25

Jose M Castellanos

19-Jun-03 0:25

Hello to everyone again:
I am experiencing a troubling problem with stl strings. I will try to be as much precise as possible.
I have this definition, as my DLL must work under WIN32 and WINCE

<br />
#ifdef _UNICODE<br />
#define __tstring std::wstring<br />
#else<br />
#define __tstring std::string<br />
#endif<br />

One object (CContainer) has to build an string with different information obtained from a structure.

<br />
const TCHAR* CContainer::GetCurrentCommandText()<br />
{<br />
  CCommands::LPCOMMAND pCommand = GetCurrentCommand();<br />
  __tstring sReturn;<br />
  sReturn.clear();<br />
  if (pCommand)<br />
  {<br />
    CCommandToTextConvert* pText;<br />
    pText= new CCommandToTextConvert(pCommand);<br />
    sReturn.append(pText->GetSVOrigin());<br />
    sReturn.append(pText->GetSVDestination());<br />
  }<br />

GetSVOrigin and GetSVDestination have a similar code. I'll show GetSVOrigin:

<br />
const TCHAR* CCommandToTextConvert::GetSVOrigin() const<br />
{<br />
  __tstring s;<br />
  s.clear();<br />
  if (m_pCommand->dLong > 0)<br />
  {<br />
    s.append(_T("Origin: "));<br />
    s.append(m_pCommand->sOrigin);<br />
  }<br />
  //Here the string is correct, someting like "Origin: main street"<br />
  return s.c_str();<br />
  //But the function returns something like "@X#R" (different each time)<br />
}<br />

The problem, as mentioned in the code is that when returning, the string gets spoilt. If I make s.c_str() before returning, the result is right. As a result, when trying to append the strings returned by the functions, as each one is wrong, the result is wrong^2

I also tried to do

<br />
	const TCHAR* sFoo;<br />
	sFoo= new TCHAR[200];<br />
	sFoo = s.c_str();<br />
	return sFoo;<br />

But the problem remains the same

What on earth can be the problem? Answers will be really welcomed.

José M Castellanos. Troubled rookie programmer WTF | :WTF:

Re: STL string problem

Jonas Larsson19-Jun-03 2:11

Jonas Larsson

19-Jun-03 2:11

Jose M Castellanos wrote:
//Here the string is correct, someting like "Origin: main street"
return s.c_str();
//But the function returns something like "@X#R" (different each time)

You are returning a const TCHAR* to a local variable. After the function exits, that memory is freed, and your pointer is pointing to garbage.

Jose M Castellanos wrote:
const TCHAR* sFoo;
sFoo= new TCHAR[200];
sFoo = s.c_str();
return sFoo;

You are still returning a pointer to a local variable here (+ leaking 200 * sizeof(TCHAR) bytes).

Jose M Castellanos wrote:
Answers will be really welcomed

Potential memory leaks aside, if you want this to work you have to copy the string to the buffer you create:
_tcsncpy(sFoo, s.c_str(), 200);
though changing you interface to something like:
bool CCommandToTextConvert::GetSVOrigin(TCHAR* buff, int& size) const
where you allocate (and deallocate) the memory outside the function is a better solution.
Note: You will still have to copy the string to buff.

HTH
Jonas

“Our solar system is Jupiter and a bunch of junk” - Charley Lineweaver 2002

Re: STL string problem

Jose M Castellanos19-Jun-03 3:12

Jose M Castellanos

19-Jun-03 3:12

Thank you Jonas:

You're right, the variable is a local one and it's destroyed. I didn't realize before because these functions are adaptations of a previous one in which the returned variable was a member variable. Thus the m_string.c_str() was not destroyed after exiting.

Sometimes, trees don't let you see the forest .... that's what happened this time.

My solution finally has been adding a member variable that is the one returned.

<br />
m_sText.clear();<br />
m_sText.append(s);<br />
return m_sText.c_str();	<br />
<br />

Datatype misalignment

Cedric Moonen18-Jun-03 23:43

Re: Datatype misalignment

18-Jun-03 23:43

Hello!

I have a structure that contains several informations. This structure can be read directly from a file. In this file I have a "memory copy" of the structure, so I just have to make a fread (with the adress of the structure as first parameter) to import the complete structure. For compatibility, I NEED (!!) to have this structure with a packing alignment of 1 byte:

#pragma pack(1)
struct SOMESTRUCT
{
     ....  //Some fields here
     char data[];    //Buffer that will hold data in a single block
}
#pragma pack()    //restore to original byte alignment setting

This works fine when I read the structure in the file.
The problem occurs when I try to "put" data in the data field:

SOMESTRUCT* temp = .....;  //Initialized here from another function, works fine
int SomeValue = 3;
*((int*)temp->data)=SomeValue;  //Exception thrown here: datatype misalignment !

This works fine on the emulator but not on the remote device !!
So, I really don't know what to do!!

Thanks for help Smile | :)

Jonas Larsson19-Jun-03 2:51

Jonas Larsson

19-Jun-03 2:51

cedric moonen wrote:
This works fine on the emulator but not on the remote device !!

If I remember correctly, datatypes like int needs to be placed on even (or was it divisble by 4) memory addresses on Windows CE. Its unclear to me if your char data[] will be placed at an illegal address for an int, but that might be it.

A workaround would be using byte-wise copy, or perhaps re-order the struct.

Jonas

“Our solar system is Jupiter and a bunch of junk” - Charley Lineweaver 2002

Re: Datatype misalignment

Cedric Moonen19-Jun-03 3:04

19-Jun-03 3:04

Hi, thanks for suggestion.

I replaced *((int*)temp->data)=SomeValue; by a memcpy and the bug disapeared !! Thanks a lot Smile | :)

file opening problem

Cedric Moonen18-Jun-03 4:12

18-Jun-03 4:12

Hello, I try to open a file using FILE *fopen( const char *filename, const char *mode ); but the function returns NULL. The file exists and is in the same directory than my executable.
I tried with the emulator (the path is correct) and on the device and it doesn't work!
Is it possible that the "working directory" of the executable is not his own directory ???

Any idea?
Thanks

João Paulo Figueira18-Jun-03 7:04

18-Jun-03 7:04

cedric moonen wrote:
FILE *fopen( const char *filename, const char *mode );

Oh, boy... Eek! | :eek:

Windows CE means UNICODE! So, never ever forget to use the wide char versions of everything. Forget char, use TCHAR! Also, fopen will NOT work, use _wfopen. Check the help file in order to find all wide character versions of the functions you would use on a desktop.

Cedric Moonen18-Jun-03 20:53

18-Jun-03 20:53

Hi !

Thanks for response.
First, fopen is supported. Taken directly from the MSDN help (from win CE !):
Remarks
The fopen function opens the file specified by filename. _wfopen is a wide-character version of fopen; the arguments to _wfopen are wide-character strings. _wfopen and fopen behave identically otherwise.

If I still want to use char* in winCE, that's because I want to import some of my desktop libraries (I cannot write everything again). So, if char is supported for some functions (like fopen), I won't change everything !

Second, the "solution" to the problem: I made some test (open a file in write mode so I can check where is the default directory). The error is what I supposed it is: the default directory is not the directory of the executable, it's the "main root". So, I have to specify complete path Frown | :(

Anyway, thanks for help Wink | ;)

!

PS: I think I will post some silly questions like that for a while 'cause it's the first time I work on a PocketPC and I worked a lot before on desktop version... Smile | :)

João Paulo Figueira19-Jun-03 3:22

19-Jun-03 3:22

cedric moonen wrote:
First, fopen is supported.

It is, but are you reading ANSI or UNICODE content? Are you specifying ANSI or UNICODE filenames and modes? When I moved to CE, I forgot about ANSI just to make my life less miserable, and it worked.

cedric moonen wrote:
So, I have to specify complete path

Yes, CE is a bitch.

Is it working, now?

Cedric Moonen19-Jun-03 3:55

19-Jun-03 3:55

João Paulo Figueira wrote:
Are you specifying ANSI or UNICODE filenames and modes?

I just open it for reading ("r") and that works fine. The contents are normal string that are stored in char*.

João Paulo Figueira wrote:
When I moved to CE, I forgot about ANSI just to make my life less miserable, and it worked.

Yep, but I cannot do that: I have a huge library that was developed on desktop environment and I want to reuse it (rewrite everything will take me really too much time) and I need to be compatible with the file format from my desktop computer (they need to understand each other). So, I have no choice: I will need to use ANSI string and convert them to UNICODE when they are not supported Frown | :(

!
But I think I'll find a way out Wink | ;)

!

João Paulo Figueira wrote:
Is it working, now?

Yes, it is Smile | :)

!

Anyway, thanks Wink | ;)

Jonas Larsson19-Jun-03 2:57

Jonas Larsson

19-Jun-03 2:57

cedric moonen wrote:
Is it possible that the "working directory" of the executable is not his own directory ???

Windows CE does not support 'working directories'. You will have to supply the full path to the file you wish to open. GetModuleFileName can be used to find the path to the exe.

Jonas

“Our solar system is Jupiter and a bunch of junk” - Charley Lineweaver 2002

Cedric Moonen19-Jun-03 3:10