I am using the xojo report and the interface reports.dataset to get the records from the listbox. 32bit works fine
but 64 bit doesn’t give me the content of a report.
Are there any issues with 64 bit ?
Possibly. Could you try narrowing it down and filing a bug report?
All xojo reporting examples are affected when compiling in 64 bit. In my own application I don’t see any Text.
32bit
http://www.directupload.net/file/d/4193/ikwm7ngo_png.htm
64bit:
http://www.directupload.net/file/d/4193/3zibomys_png.htm
Sounds similar to my Feedback Case 41733
Yes, I’ve supported it.
Can anyone from Xojo tell us if this is likely to be resolved any time soon?
It was verified by Stephane a year ago and with 2016 4.1 the problem still exists. As all my apps require reports so I can’t deploy anything in 64 bit. It’s disappointing when I can see great performance benefits on sample builds but can’t actually give users the new versions.
And I have lent my support to 41733 as that’s the exact issue.
Literally JUST compiled the listbox example as 32 bit and 64 bit and I get identical results from them on 10.11.6
If someone cares to add a sample that doesn’t work + steps to reproduce it I’ll be happy to look at it
But as it sits right now I’d be closing this report as “Cant reproduce”
Does it ONLY manifest IF you actually print to paper (as it sure doesn’t look different in a PDF or on screen)
EDIT : just printed the results to my HP MFP 1212 and they look as identical as I can discern
I’m not sure how that can be the case given Stephane verified the behaviour. Are you saying you believe it’s fixed in later builds? I just built “List of Orders” in the Orders folder of 2016 4.1 and it is showing the tiny text on Yosemite 10.10.5.
The PDF can be found here - http://www.sweatmedia.com/List_Of_Orders.pdf
Here are the PDFs from two of the other included examples:
http://www.sweatmedia.com/List_Of_Products.pdf
http://www.sweatmedia.com/Orders_by_Company.pdf
In answer to your question, they are wrong in the PDF preview and wrong at the printer - the result is the same.
- stephane is not available so I can ask him how he verified this. That is sometimes not in case notes & we do go back & forth internally about cases sometimes.
- I literally opened 2016r4.1, loaded the sample the case mentioned, ListBoxReport, set the name to include “32” at the end and compiled a 32 bit version
- I then altered the name to remove the 32 and added 64 and switch to compile a 64 bit version. Built that.
- quit the IDE and ran both side by side and compared on retina and non-retina screens - no visible differences I could see on screen or in PDF’s
- printed from both to my HP. Again no differences I can find.
This points out a few things to me
If you have an example that shows that its not functioning please says so in the notes in Feedback.
There was only one example mentioned, I used that and saw no differences. Hence why I’d have said “Cant reproduce” which is really “given the explanation & samples the issue identified cannot be reproduced”
Had I closed the case as not reproducible and gone to sleep, out to my shop or out skating at that point I might never have seen your follow up comment.
And without your additional comments from this thread on the case it might have simply been left closed.
Multiple examples are not a bad thing.
Always feel free to add to a case with more examples that illustrate the issue.
NOW, all that aside, I did try the example you mentioned and I do see different results
I’ll have a look
But that does not equate to “and this will get fixed ASAP”
I have a list of cases to get fixed for 2017r1 and some will take me many days to resolve
So no promises
Ah well there yah go
The example you referred to explicitly set the MAX resolution to 300DPI which when you draw everything & scale it makes things tiny
NOT doing this when generating the PDF makes things behave MUCH better
This makes more sense since the underlying engine is the same and should not be right “sometimes” and not others
I have updated the feedback report to include the names of the included Xojo examples which fail along with PDFs of the issue.
I DONT see the issue using the ListboxReporting example - Im guessing it is generated somehow differently to the database examples.
As for whether it will be fixed ASAP, it just seems odd that something which was verified 12 months ago by someone at Xojo has had no attention since. But thanks for taking a look, at least I know you can see that a bug exists.
One explicitly sets the DPI to 300 (the one that doesnt work)
One doesnt (the one that does work)
Altering the one that doesn’t work to NOT explicitly set the DPI makes it behave more correctly
[quote=306880:@Kim Kohen]
As for whether it will be fixed ASAP, it just seems odd that something which was verified 12 months ago by someone at Xojo has had no attention since. But thanks for taking a look, at least I know you can see that a bug exists.[/quote]
I still have a bug report on file that is 9 years old
Of course that doesn’t hold a candle to Joes report with Apple that was a duplicate of a verified bug that is now about 20 years old
And FWIW I’d say this is the example - not a bug 
[quote=306883:@Norman Palardy]One explicitly sets the DPI to 300 (the one that doesnt work)
One doesnt (the one that does work)
Altering the one that doesn’t work to NOT explicitly set the DPI makes it behave more correctly[/quote]
I’ve just tested this with both the Xojo examples and a couple of my apps and it does make it better but not quite right. I also tried several different resolutions to see if there was one which worked properly (couldn’t find one). At this stage we’ll have to stick to 32 bit builds but hopefully this is not a major problem.
I’ll reiterate
IF you have other reproducible examples that have issues attach them to the case
The set up difference I noted is the only “bug” and that we can correct by updating the example and close the case as “fixed” which I’m sure doesn’t meet your expectations
With respect, we can see that at least 3 of the example projects demonstrate the issue and that changing/eliminating the resolution setting doesn’t fix it. Yes, it’s not as bad, but it’s not ‘fixed’ to the extent I could deploy the app. I’m not sure how sending more examples would help other than just giving more stuff to sift through. I’ll also add that this would require us to give you access to our production databases which we won’t do. The code I am using in my reports is copied directly from the example projects so won’t provide anything new.
I dont want access to your production database thanks
At least one of those example projects set up the report in a way it couldn’t be rendered correctly
By speciftying a fixed DPI of 300 when I set up my printer to be 1200 - hence the print is about 1/4 the size it should be
Fixing that so it uses the actual printer resolution the example you cited prints nicely on screen, in pdf & on paper
IF you’ve copied that example you may be doing the same thing
That doesn’t necessarily make it a bug - at least not in the engine
In the example possibly
But thats emminently correctable )which is what I said I did and things then drew fine)
So, as I said earlier, IF there is a reproducible example that shows a bug in the rendering engine I’m happy to look at it but so far the only bug is in the examples set up
Beyond that I cant fix what I can’t see
[quote=307229:@Norman Palardy]By speciftying a fixed DPI of 300 when I set up my printer to be 1200 - hence the print is about 1/4 the size it should be
Fixing that so it uses the actual printer resolution the example you cited prints nicely on screen, in pdf & on paper[/quote]
No it doesn’t - it is better but far from correct. I have updated the feedback case with print examples of 32 bit (renders correctly), 64 bit (renders as tiny text) and 64 bit with no res specified (renders larger but cuts of text, prints the wrong size and is not correct).
I can’t understand how you can think this is not a bug when there’s clearly an issue - and not just for me or the examples. The feedback report was created and commented on by others, not me.
Did you happen to add an example that reproduces this issue ?
Without them we have to try & figure out how to first reproduce the situation you’re seeing
This takes time & makes it take longer to get a fix - if one is needed at all
And if our example is NOT exactly how you get the results you get then we end up not fixing the right issue.
Or we do nothing because we set up an example that is correctable by adjusting print settings or something else fully in your control.
Dont get me wrong IF there is a sample app that shows this I’ll be more than happy to look
And then maybe the issue you’re talking about gets fixed
But at this point there isn’t anything on that report that is actionable
Seriously, you seem less interested in fixing it than you do arguing about it. I shouldn’t need to add an example as you already have three which are supplied by Xojo and detailed yesterday.
The Xojo example projects give IDENTICAL results as explained yesterday and the PDFs demonstrating this were also uploaded. I have already specified three of the projects which are wrong. I can send you 50 variations which will all be broken in the same way but I’m sure that won’t be helpful.
Regardless, I have added a project to make it even more obvious what the problem is, along with both 32 and 64 bit executables which demonstrate the issue. Sad that a paying customer has to waste time highlighting an issue which was identified a year ago and demonstrated 3 times again yesterday…