xBrowse error with 16.01 and resource

[TimStone]

I have a new problem with xBrowse in 16.01. In the first column I display one of three bitmaps depending on the value of two different fields. I have used this process for many years and it has worked fine. The resources are drawn from the linked in .res file and they are definitely included.

Now, in 16.01 it suddenly is providing an error. Here are the relevant pieces of code.

Code: Select all  Expand view

// Assign the bitmaps to the array
    aBmp := { LoadBitMap( GetResources( ) , "CM1" ), ;
        LoadBitMap( GetResources( ), "CM2" ), LoadBitMap(GetResources( ), "CM3") }

.....................................................Other code


// Assign the bitmap options to the first column
    add oCol to oLbxo header "Stage" ALIGN CENTER BITMAP
    oCol:AddResource("CM1")
    oCol:AddResource("CM2")
    oCol:AddResource("CM3")
// And select the value to display
    oCol:bBmpData   := { || IIF( oWrkOrd:totals, 3, IIF( oWrkOrd:ordnot, 1,2 ) ) }


 

The problem has been traced to the oCol:AddResource functions, and it results in the programming going into a Windows error ( Test.exe has stopped working ). By going through the code step by step, I found the error to be here, and if I comment out the last 4 oCol: calls, it works perfectly.

Tim

[nageswaragunupudi]

Our test here:

Code: Select all  Expand view

#include "FiveWin.Ch"

//----------------------------------------------------------------------------//

REQUEST DBFCDX

//----------------------------------------------------------------------------//

function Main()

   local oDbf, oDlg, oBrw, oCol, oFont

   oDbf  := TDataBase():Open( nil, "CUSTOMER", "DBFCDX" )

   DEFINE FONT oFont NAME "TAHOMA" SIZE 0,-14

   DEFINE DIALOG oDlg RESOURCE "TEST" FONT oFont TITLE FWVERSION

   REDEFINE XBROWSE oBrw ID 101 DATASOURCE oDbf

   ADD TO oBrw DATA oDbf:First HEADER "Name" WIDTH 100
   ADD TO oBrw DATA oDbf:Age   HEADER "Age"  WIDTH 50
   ADD oCol TO oBrw HEADER "BMP" ALIGN CENTER BITMAP WIDTH 50

   // oCol:AddBitmap( { "GREEN", "RED" } )  // new syntax
   oCol:AddResource( "GREEN" )    // using old syntax for testing
   oCol:AddResource( "RED"   )

   oCol:bBmpData  := { || oDbf:Age % 2 + 1 }

   ACTIVATE DIALOG oDlg CENTERED
   RELEASE FONT oFont

return (0)

//----------------------------------------------------------------------------//
 

RC file

Code: Select all  Expand view

TEST DIALOG 6, 15, 306, 227
STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU
CAPTION "TXBrowse demo"
FONT 8, "MS Sans Serif"
{
 DEFPUSHBUTTON "OK", IDOK, 252, 211, 50, 14
 CONTROL "", 101, "TXBrowse", 0 | WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_HSCROLL | WS_TABSTOP, 4, 5, 297, 202
}

GREEN    BITMAP "..\bitmaps\level1.bmp"
RED      BITMAP "..\bitmaps\level2.bmp"
 

Tested by placing the prg and rc in fwh\samples folder.

Result:


We do not understand the need for this code

/ Assign the bitmaps to the array
aBmp := { LoadBitMap( GetResources( ) , "CM1" ), ;
LoadBitMap( GetResources( ), "CM2" ), LoadBitMap(GetResources( ), "CM3") }

We request you to help us by providing a self contained sample, which we can build and test at our end, which can reproduce your problem so that in turn we can help you.

[TimStone]

Let's work with your example, and let me answer your question:

1) The array was a suggested solution ( from an example or otherwise ) and has been in place for 10 to 15 years. That's how long this format has been working. It makes no difference if I comment it out.
2) The code works fine with FWH 15.12. In fact I reverted back to that and re-built it, and all is good. Thus the problem arose with 16.01.
3) Please note, you are using 2 bitmaps, and 1 field. The example uses 3 bitmaps, and two fields. IIF the value of the first field is true, then it's bitmap is shown. If not, then IIF the value of a 2nd field is true, bitmap 2 is shown. If that second field is false, then bitmap 3 is shown.
4) The failure can be isolated to the oCol:AddResource( "CM1") function. If I comment out the others, it still dies with AddResource( ). Also, please remember this is a problem that arose with 16.01 and was not there in 15.12.

Tim

[nageswaragunupudi]

4) The failure can be isolated to the oCol:AddResource( "CM1") function. If I comment out the others, it still dies with AddResource( ). Also, please remember this is a problem that arose with 16.01 and was not there in 15.12.

1) Can you please try setting oBrw:lGDIP := .f., immediately after defining the Browse?
( oBrw or whatever variable you used )

2) We need to check internals of our library. If there is someway you can send me the resource "CM1"
I mean that small part of the resource file along with that bitmap or image file. I am trying to ascertain if this is what is creating problem

[TimStone]

Setting lGDIP := .f. resolves the problem in that case, and it works as expected. I'm seeing a couple of other places where I have problems and I will see if that resolves it.

I will email you all three bitmaps.

Tim

[TimStone]

The problem also occurs with SetCheck() and is resolved with lGDIP := .f.

That requires a lot of recoding to add that throughout.

NEW DISCOVERY: I found this problem occurs when building the program with xBuilder ( xHarbour.com ). It works correctly when building with Harbour and MSVC 2013. Most of my testing is done with the Harbour/MSVC so I didn't catch it, but distributed programs are predominately xHarbour.

[nageswaragunupudi]

That requires a lot of recoding to add that throughout.

We do not expect you to do that. We'll make it a lot easier. Just please wait a little.
We tested with bcc7 and xharbour too.

[nageswaragunupudi]

Thanks for sharing your bitmaps. We tested there are no issues with bcc7 with xharbour or bcc7 or msvc with Harbour.
The problem is narrowed down to the xhb version you are using. We would be interested in knowing the experience of other xhb users.

We may keep improving fwh in future too and at the same time we need to find how to except xhb built applications. We shall very soon find a solution for this.

[TimStone]

Thanks for working on this.

I think a lot of people still use xHB commercial. In my case, it is the very latest solid build they have provided, so it is current.

This problem can be isolated to the GDI+ changes made in 16.01. 15.12 does not have the problem. Yes, it is specific to the xHarbour commercial build which uses the Pelles compiler, and it does not exist with Visual Studio 2013 plus Harbour.

Tim

[Antonio Linares]

Tim,

I sent you yesterday the new libs for testing with xhb.com

Are they ok ? thanks

[TimStone]

I emailed you right away that it still does not work


Sent from my iPhone using Tapatalk