C / C++ / MFC

Re: Migrating old project to VS2008 - resource file errors

4-Aug-16 3:36

I would suggest the best way forward is to open the .RC file in the text editor (either in VS or using Notepad) and see if you can tidy up anything that looks out of place. And without seeing the resource statements it's impossible to guess what that may be.

charlieg4-Aug-16 8:07

Re: Migrating old project to VS2008 - resource file errors

4-Aug-16 8:07

Richard - are you suggesting I tidy up Microsoft's area? My resource file hasn't changed.

Richard MacCutchan4-Aug-16 8:22

Re: Migrating old project to VS2008 - resource file errors

4-Aug-16 8:22

No I am just suggesting that other things have changed and an old resource file may not be compatible with the new versions of the resource compiler. But if you think it is Microsoft's problem you can always try one of their support forums.

leon de boer7-Aug-16 7:47

leon de boer

7-Aug-16 7:47

RC and RES files have always been dangerous to rely on. Generally hold your bitmaps as bitmaps, and your dialog, menus and text as standard text files. Then script them or manually drag and drop them when you go onto a new version of Visual Studio.

You are basically asking Microsoft to make everything backwards compatible just so you can just pick up a prior project and compile it on the later version. The toolchain is long and subject to change and that is NEVER GOING TO HAPPEN. You always have the option to stay with and compile your code on VS2008.

A resource file is an ancillary file, do you expect your old manifest files to be backward compatible on the new compiler as well?

I am with Richard if you think Microsoft should support stuff to this level try the forums. I however feel you are being totally unreasonable its a few minutes work to deal with and you are almost certainly going to get a longer list of code changes that you will be required to vet with the new version. Out of interest how many code warnings and deprecated calls did you get when you loaded the old code.

In vino veritas

Re: Migrating old project to VS2008 - resource file errors

charlieg8-Aug-16 2:02

Re: Migrating old project to VS2008 - resource file errors

8-Aug-16 2:02

Well "

Quote:
RC and RES files have always been dangerous to rely on.

I understand your comments, but your first statement rather surprises me. Over the past 13 years or so, I've moved through EVC++, VS6, 2008, 2010, 2013, and now 2015. Never has it occurred to me that I should worry about the RC file. FWIW, others have had this problem prior to me.

Regarding backwards compatibility, not sure why you think I even suggested such a beast. But, if I use the "import source from an existing project", I sort of expect something semi functional. I don't think that is unreasonable.

I know it's fixable, as soon as I find the solution, I'll close out my own question.

leon de boer8-Aug-16 7:11

leon de boer

8-Aug-16 7:11

I am surprised you never ran into the problem with RC files when you went from 16 bit to 32 bit programs because the header includes the language id and the Resource compiler used to always spit it about language not being set.

The solution is dead simple and was given to you by Richard ... open the RC file with a text editor its a straight text file.

Just pick the body up onto the clipboard and post it into a new empty resource file associated to the project. That is why we can't work out why you are stressed over it as it's like 1 min work with a text editor.

All the Resource compiler is complaining about it the header information in the old RC file which has includes directories that are wrong or header commands that aren't supported. The reason for that is most likely you used a resource kit wizzard and it's directing to that old directory or deprecated. You might have one or two resources you are using from the kit which will be trivial junk like ID's or perhaps an icon and if you have any just make your own replacements getting rid of dependency on the old kit.

I guess I should ask do you know what the RC body should look like and where the header ends? Even if you aren't familiar the format detail is so obvious I am sure if you spent 10 min looking at the file you will work it out. If you get stuck just paste the top 10-20 lines of the file and we can help.

In vino veritas

modified 8-Aug-16 13:33pm.

Re: Migrating old project to VS2008 - resource file errors

charlieg9-Aug-16 7:50

Re: Migrating old project to VS2008 - resource file errors

9-Aug-16 7:50

With insufficient information, I missed what Richard was saying. I have to laugh though. When Windows was 16 bit, I was off in Unix land. So, I've not made this transition. I did just get done with migrating the project as a whole, so the suggestion certainly makes sense.

Quote:
Just pick the body up onto the clipboard and post it into a new empty resource file associated to the project. That is why we can't work out why you are stressed over it as it's like 1 min work with a text editor

.

now I understand, sorry for being so dense. Thumbs Up | :thumbsup:

I'll get to this in the afternoon and see where it leads me.

modified 9-Aug-16 16:38pm.

charlieg24-Sep-16 0:48

how to be sure each child class inherits a method?

24-Sep-16 0:48

Well, to update this query by me so that someone might be helped in the future:

VS2008 does not even come close to properly converting a project from eVC++. There are so many macros left undefined from the conversion that VS2008 is not able to handle its own includes let alone the application. The problem has absolutely ZERO to do with any specific resource file. It's caused by the pathetic migration effort made by VS2008.

Save yourself some time and (a) create a simple smart device project appropriate for you in VS2008. Then (b) migrate the existing code base in one at a time. Even then your dialog resource processing may need manual intervention.

modified 8-May-17 17:18pm.

FriendOfAsherah2-Aug-16 19:58

Re: how to be sure each child class inherits a method?

2-Aug-16 19:58

I have a straight class hierarchy.
The base class only has a method F() which calls another method P().
This method P() has to be implemented in all of the child classes and is called by polymorphism.

How can I get sure (at compile time) that all child classes implement this method P()?

class CBase 
{
private:
  virtual void P() { printf("CBase::P\n"); }
public:
  void F() { printf("Base: F()->P(): "), P(); }
};

class C1 : public CBase
{
  private:
    virtual void P() override { printf("C1::P\n"); }
};
class C2 : public C1
{
  private:
    virtual void P() override { printf("C2::P\n"); }
};

void main()
{
  CBase* p = new CBase();
  p->F();
  p = new C1();
  p->F();
  p = new C2();
  p->F();
}

The above is the structure, when all is correct and will result in:
Base: F()->P(): CBase::P
Base: F()->P(): C1::P
Base: F()->P(): C2::P

Now I made a mistake and forgot to implement P() in class C1

class C1 : public CBase
{
  private:
    //virtual void P() override { printf(&quot;C1::P\n&quot;); }
};

the compiler doesn´t error and it will result in
Base: F()->P(): CBase::P
Base: F()->P(): CBase::P
Base: F()->P(): C2::P

The only Idea is to use an Interface declaring P() abstract.
But since C2 is derived from C1 from CBase how to do?
Followeing code will show up an error on missing P(), but also shows up warnings when all is correct:
warning C4584: 'C1': base class 'PI' is already base of 'CBase'
warning C4584: 'C2': base class 'PI' is already base of 'C1'

C#

struct PI { virtual void P() abstract; }; class CBase : public PI { private: virtual void P() { printf("CBase::P\n"); } public: void F() { printf("Base: F()->P(): "), P(); } }; class C1 : public CBase, public PI { private: virtual void P() override { printf("C1::P\n"); } }; class C2 : public C1, public PI { private: virtual void P() override { printf("C2::P\n"); } };

also it doesnt help at all because now I have to be sure to derive C1,C2, ... from PI too, not only from its parent

So what I need is "method P() has to be declared in all child classes!- error if it is not"

Richard MacCutchan2-Aug-16 20:28

Re: how to be sure each child class inherits a method?

2-Aug-16 20:28

If you make P a pure virtual function, then the compiler will spot if it has not been implemented:

C++

virtual void P() = 0; // a pure virtual function

FriendOfAsherah2-Aug-16 20:49

Re: how to be sure each child class inherits a method?

2-Aug-16 20:49

in which class, where to put this?
in CBase? -> then CBase doesnt have its P() method itself
in struct PI? ->still used this
"=0" is same systax like "abstract"

Richard MacCutchan2-Aug-16 21:03

Re: how to be sure each child class inherits a method?

2-Aug-16 21:03

You put it in the CBase class then every class that inherits CBase must implement P.

FriendOfAsherah2-Aug-16 21:29

Re: how to be sure each child class inherits a method?

2-Aug-16 21:29

does not work ...
I can ommit P() in C2 without compile error because its stil defined in C1
also I miss the code of CBase::P() itself
like:

class CBase 
{
private:
  virtual void P() abstract; //{ printf("CBase::P\n"); }     // <= and whats about that code?? 
public:
  void F() { printf("Base: F()->P(): "), P(); }
};

class C1 : public CBase
{
  private:
    void P() override { printf("C1::P\n"); }
};
class C2 : public C1
{
  private:
    //void P() override { printf("C2::P\n"); }
};

Richard MacCutchan3-Aug-16 3:15

Re: how to be sure each child class inherits a method?

3-Aug-16 3:15

The function C1::P() is declared private so it is not accessible in class C2. However, it is difficult to see exactly what problem you are trying to solve here.

FriendOfAsherah3-Aug-16 19:23

Re: how to be sure each child class inherits a method?

3-Aug-16 19:23

The structure is:
CBase <- C1 <- C2 <- ... etc
so straigt inheritance

CBase contains the main method CBase::F() which does all calculations needed.
And this method F() calls P() which should be choosen by inheritance (polymorphism)
CBase::F() { ...; P(); ... }

If I have CBase* b = new C2() than C2::P() will be called.
If I have CBase* b = new C1() than C1::P() will be called.
because of P() is a virtual method, overridden by C1::P().. C2::P() etc

now I miss C1::P() (forgot to add it) =>
if CBase b=new C1() then CBase::F() will call CBase::P() instead of C1::P() because there is no C1::P()

the override clause also tells the compiler to check if C1::P(), C2::P() match their parents P().

All is cointained by a complex chaotic SW-project which I will clean by small steps.
The idea behind:
P() is a call to a factory class which creates objects dependend on parameters AND on the class from which is called

CBase::P(int type) creates objects of CPbase_<type> so CPbase_1, CPbase_2...
C1::P(int type) creates obejcts of CP1_<type> so CP1_1, CP1_2...
C2::P(int type) creates obejcts of CP2_<type> so CP2_1, CP2_2...
etc...

CBase::F(switch,type) : if (switch) P(type) else CBase::P(type) ...
So if switch is set call the factory "of the class", else call the factory of CBase

example:
Cbase b = new C1();
b->F(true, 3) will create an object of C1_3()

All the pointers are stored in a list and for each element in the list the creation-funbtion F() is called

list ... C1*,CBase*,C3* etc ...
foreach element in list , element->F(switch,type) ...

Krishnakumartg21-Sep-16 20:19

Krishnakumartg

21-Sep-16 20:19

1. Change all private into 'protected'
2. For testing purpose do trial and error of pure virtual test on each level.

Best wishes

CrichEditCtrl::Find returns zero when second RichEdit is Created as a Child of A Different CDialog

ForNow2-Aug-16 16:38

Re: CrichEditCtrl::Find returns zero when second RichEdit is Created as a Child of A Different CDialog

2-Aug-16 16:38

Hi
I have a CrichEditCtrl that works fine. However when the user Selects to view some other data in a Different Cdialog/CRichEditctrl. The first stops working and returns a zero

I display the Text I am Searching for and the Returned code From FindText (in the caption bar)

The Text looks fine However as soon as The Second Cdialog/RichEdit are created the return from the First CDaliog/RichEdit returns a zero

I double checked things as resource id of both RicheditCtrl's and they are different

Richard MacCutchan2-Aug-16 20:24

Re: CrichEditCtrl::Find returns zero when second RichEdit is Created as a Child of A Different CDialog

2-Aug-16 20:24

Are you saying both dialogs are open at the same time?

ForNow2-Aug-16 23:25

Re: CrichEditCtrl::Find returns zero when second RichEdit is Created as a Child of A Different CDialog

2-Aug-16 23:25

Yes Actually this is the 3rd CDialog/CRicheditCtrl Pair That I have in my application The parent window is the First Cdialog/CrichEditCtrl. However After this is Created the Find functionality of the Richedit which is a child control of my main (for lack of a better term)CDialog stops working

Richard MacCutchan3-Aug-16 3:11

Re: CrichEditCtrl::Find returns zero when second RichEdit is Created as a Child of A Different CDialog

3-Aug-16 3:11

Without a lot more detail, including the code, it is anyone's guess. However using dialogs to open other dialogs does not sound like the best design.

leon de boer4-Aug-16 5:19

leon de boer

4-Aug-16 5:19

If you can see the problem starts when it's returning zero then you have an obvious debug point.

Place a debug point inside an if statement on the zero return ... when it breaks follow the steps backwards. The hard part is generally finding a debug point with this sort of problem but you have that already.

In vino veritas

Re: CrichEditCtrl::Find returns zero when second RichEdit is Created as a Child of A Different CDialog

ForNow4-Aug-16 5:29

Re: Had a number of controls CTEXT and I didn't allocate Corresponding Ctatic Pointers thanks

4-Aug-16 5:29

I added he following code want to see what is in the rich edit

C++

linechar = myedit->FindText(FR_DOWN , &listtext);
if(linechar == 0)
{
	
	CFile dumpfile;
	CFileException e;
	TCHAR* pszFileName = _T("F:\\DUMPLIST.LST");
	if(!dumpfile.Open(pszFileName, CFile::modeCreate | CFile::modeWrite, &e))
		MessageBox("file could not be opened");
	EDITSTREAM dmp;
	   dmp.dwCookie = (DWORD_PTR) &dumpfile;
        dmp.pfnCallback = (EDITSTREAMCALLBACK)dumpit;
		myedit->StreamOut(SF_TEXT,dmp);
}

static DWORD CALLBACK dumpit(DWORD_PTR dwCookie, LPBYTE pbBuff, LONG cb, LONG *pcb)
{
   CFile* pFile = (CFile*) dwCookie;

   pFile->Write(pbBuff, cb);
   *pcb = cb;

   return 0;
}

ForNow5-Aug-16 5:29