FiveTech Software tech support forums

We are converting the 16-bit FW application to the xHarbour (October05 and FWH december 05
For now, it goes well.

However, we have a strange problem. We are using RC file to include all resources into EXE. Nothing specialy.
But, we have a problem because some of the BITMAP resources are not visible on Button bar.
If we change the name of the resource it sometimes helps and btimap is shown, but sometimes not.
Also, sometimes the resource bitmap is shown when we change the name, but the other resource bitmap is not shown now, even it was visible why the first was not?
And not only that, when we now change the resource name of this second bitmap, the third one is not visible, even it was visible all the time, or the first one again not visible (no order)?
And finaly, sometimes when we need to change some resource name to be able to see it at all, it happens that on or more other bitmaps are now not visible....

Totaly confused, any help?
The simple code snippet:

DEFINE BUTTON oBtn_Changes resource 'BTN_MULTI_CHANGES' group OF oBar_3 ;
ACTION ( MULTI_CHANGES(), oBrw:Refresh() ) ;
TOOLTIP "Master File Multi Changes" ;
MESSAGE "Master File Multi Changes"

Ordinary, but we are stacked...

Boris,

> 'BTN_MULTI_CHANGES'

What other resources names are you using ?

Hi Boris, good to hear from you.

I notice that your resource name is quite long. I wonder if there is a name length maximum, especially since WorkShop is 16bit. Perhaps if you shorten all the bitmap names?

James

James,

Yes, I agree with you, thats why I asked him for the other resources names. I guess that if he uses shorter ones, the problem will be solved.

@James
Nice to be again among the friends

@Antonio
Yes Antonio, this was my first thought, and will try to shorten the names, even it will be a lots of work, the application is extremly complex and so many resources involved
The funy thing is, 16-bit version of the same app, does not make me any problem...
I also think the problem is in long resource names, because there is no rule which resource will fail to show up, after I chnage one of the names. Like "domino effect" unfortunately...

Another strange thing I noticed is about the database names when trying to open them:
database "boris.DBF.DBF" (notice two times .DBF !) opens without problem in 16-bit (Clipper FW) application!? Seams clipper checks first 8 letters up to first occurence of dot in .DBF and then strips out from the END the file extension, so it resolves to "boris.DBF"
xHarbour is more strict, it will try to open "boris.DBF.DBF" without stripping out anything and therefore reports an error...

Anyway, I will check the resource names and if it was the problem, hope someone else will be saved of hours of working and searching for problem solution

Boris wrote:@James
Nice to be again among the friends

@Antonio
Yes Antonio, this was my first thought, and will try to shorten the names, even it will be a lots of work, the application is extremly complex and so many resources involved
The funy thing is, 16-bit version of the same app, does not make me any problem...
I also think the problem is in long resource names, because there is no rule which resource will fail to show up, after I chnage one of the names. Like "domino effect" unfortunately...

Another strange thing I noticed is about the database names when trying to open them:
database "boris.DBF.DBF" (notice two times .DBF !) opens without problem in 16-bit (Clipper FW) application!? Seams clipper checks first 8 letters up to first occurence of dot in .DBF and then strips out from the END the file extension, so it resolves to "boris.DBF"
xHarbour is more strict, it will try to open "boris.DBF.DBF" without stripping out anything and therefore reports an error...

Anyway, I will check the resource names and if it was the problem, hope someone else will be saved of hours of working and searching for problem solution

Boris

I have a lot of long file names resources in RC files and my xharbour app works quite OK.

What are you using Xharbour commercial or xharbour.org ? In both cases, if you have many rc files , you would have to make them look to the linker as one rc file, otherwise you will have dialog errors like you mention. You can use something like this

define a rc file name it myprogram.rc
In this rc file try to add all the others like the sample below

#include "CBATIMAN.rc"
#include "CBATIMA.rc"
#include "CBATIDEV.rc"
#include "CBATI.rc"
#include "CBATICOM.rc"
#include "CBATISAV.rc"
#include "CBATIVEH.rc"
#include "CBATIPAY.rc"


HTH

Richard

If you are using Xharbour commercial, make sure you are not specifying more than one rc file in the xbp file, only first one will be used.

I have only one RC file and am not sure if is too big maybe... over 150 dialogs defined, and about 70 BMP files listed. The size about 300K
I doubt this is the problem.

Using commercial (professional) xHarbour version.

I am in the process of shortening resource names, we'll see...
Regards

Unfortunately, no problem solved
I replaced all long resource names with the names which are up to 10 characters long.
The same problem persists...
Using xHarbour October 2005 and FWH December 2005 (I think but I got it on December 2005)

Should I take a look into some class or something.
It is very frustrating, changing the name of one button bar image, another two are not shown which were shown correctly a minute before. Then change these two names, one is shown another not, but in addition, the previous one I just changed, doesn't show this tima.
An endless loop...

Any help or advice please?

Boris wrote:Unfortunately, no problem solved
I replaced all long resource names with the names which are up to 10 characters long.
The same problem persists...
Using xHarbour October 2005 and FWH December 2005 (I think but I got it on December 2005)

Should I take a look into some class or something.
It is very frustrating, changing the name of one button bar image, another two are not shown which were shown correctly a minute before. Then change these two names, one is shown another not, but in addition, the previous one I just changed, doesn't show this tima.
An endless loop...

Any help or advice please?

Boris

You should look into xharbour.com's ng
There is a thread about this, Looks like in some cases, xbuild has a problem with dialogs.

Richard

Boris wrote:Unfortunately, no problem solved
I replaced all long resource names with the names which are up to 10 characters long.
The same problem persists...
Using xHarbour October 2005 and FWH December 2005 (I think but I got it on December 2005)

Should I take a look into some class or something.
It is very frustrating, changing the name of one button bar image, another two are not shown which were shown correctly a minute before. Then change these two names, one is shown another not, but in addition, the previous one I just changed, doesn't show this tima.
An endless loop...

Any help or advice please?

Boris
In case you do not have access to the xharbour com forum

This the reply from Ron Pinkas



<quote
Ok, the solution is very simple.

The defacto recommended practice for Dilaog IDs in resource file is to use
NUMRIC identifiers, rather than Strings.

Now, to the simple solution:

1. Add the follwoing at bottom of your main source:

//------------------------------------------------------------------------------------------------
#pragma BEGINDUMP
#include <windos.h>
#include "hbapi.h"

HB_FUNC( MAKEINTRESOURCE )
{
hb_retclenStatic( MAKEINTRESOURCE( hb_parnl(1) ), 2 );
}
#pragma ENDDUMP
//------------------------------------------------------------------------------------------------

2. To the top of of your resource file, and to the top of your source
accessing the resources, add:

#include "MyApp.ch"

3. In your Resouce file, add >ID_< prefix to your dialog names.

4. Create a new MyApp.ch with content like this (based on your xTest
sample):

//------------------- xTest.ch --------------------//
#define ID_PRE_IMP 1001
#define ID_CAD_CONFIG 1002
#define ID_CAD_CONTATOS 1003
#define ID_CAD_EXTRA 1004
#define ID_CAD_FONES 1005
#define ID_CAD_FONESVAL 1006
#define ID_CAD_MENSALIDADE 1007
#define ID_CAD_MODI 1008
#define ID_CAD_OBSERVACAO 1009
#define ID_CAD_ORCAMENTOS 1010
#define ID_CAD_OUTRO_FONE 1011
#define ID_CAD_SENHA 1012
#define ID_CAD_SOLICIT 1012
#define ID_CAD_TREINA 1013
#define ID_CAD_VERSOES 1014
#define ID_DLG_ENVELOPE 1015
#define ID_DLG_FILTRO 1016
#define ID_DLG_INDEX 1017
#define ID_DLGAGUARDE 1018
#define ID_DLGDATAEST 1019
#define ID_DLGDATACLIEST 1020
#define ID_DLGFILREC 1021
#define ID_DLGINDEXAULTATEND 1022
#define ID_DLGPENDENC 1023
#define ID_IMP_NOTA 1024
#define ID_IMP_SOLICIT 1025
#define ID_PRINT 1026
#define ID_PRINT_PROC 1027
#define ID_PREVIEW_PROC 1028
#define ID_CAD_ATEDESCR 1029
#define ID_CAD_ATENDIMENTOS 1030
#define ID_CAD_CLIENTES 1031
//-------------------- EOF ----------------------//

5. Finally, change your code from:

DEFINE DIALOG oDLG RESOURCE "PRE_IMP"

to:

DEFINE DIALOG oDLG RESOURCE MAKEINTRESOURCE( ID_PRE_IMP )

That's all, you should never again see such problem.

Ron

Richard,

Thanks a lot for your advice...
I will give it a try. However, this will take ma very much time, becouse we have so many dialogs and controls in our RC.
I am mentioning dialogs also, because we had the problem with dialogs also, then we had to change the name of the dialog whic was not created (Cannot create dialog /3) and when we change the name it was fixed. For now the dialogs shows all ok, but if xHarbour needs some other logic, we will need to probably change the dialog resource calling, the same way as controls....

I am wondering, why this was changed? ANd I didn't see any notification about that, so we spent many hours investigeting because of the bad documentation of xHarbour

Will sit down and start, I don't see any other solution.
Thanks again

Boris -

Here's something I posted on the xBuilder newsgroup some time ago that might be of help...
------------------------------------
Had a problem with my .RC file containing dialog resources, but found the
solution.

After compiling with xBuilder, the app ran fine on Win '95-'98, but quit on
XP with "Cannot create dialog" error. I discovered that some of the dialog
resources had names starting with "S_" like S_BROWSE and S_VOTERS etc. After I dropped the "S_" in the resource names, the problem disappeared. Perhaps there was some conflict with Win API naming conventions. So beware of naming resources with an underscore in this way, especially "S_".
--------------------------------
- Roger

Roger Seiler wrote:Boris -

Here's something I posted on the xBuilder newsgroup some time ago that might be of help...
------------------------------------
Had a problem with my .RC file containing dialog resources, but found the
solution.

After compiling with xBuilder, the app ran fine on Win '95-'98, but quit on
XP with "Cannot create dialog" error. I discovered that some of the dialog
resources had names starting with "S_" like S_BROWSE and S_VOTERS etc. After I dropped the "S_" in the resource names, the problem disappeared. Perhaps there was some conflict with Win API naming conventions. So beware of naming resources with an underscore in this way, especially "S_".
--------------------------------
- Roger

Roger

Unfortunately it is a specific xbuild problem, Borland will compile and link OK the same resources !!!!

Richard

@Roger
Yes, we noticed that changing the dialog or resource elements names might help. We played a lot and finaly we made it working, showing all dialogs and redefines show properly now.

@Richard
Seams this is realy xHarbour specific problem. Have no idea why is that and also is not mentioned anywhere in the documentation.
We have the app working but I do not like the solution we don't know the exact reason and the solution.
But, we do not time left to be able to research something which is to be noted to us - developers. Now it works after a several names changing (even changing some names more than once), but I would like to know how this can be overcomed for sure.
The suggested use of function seams doesn't work either, one of our fellow programmers tried it and reported stil the same problem.

Strange....