Getting a picture from a xojo.io.FolderItem

I’m receiving a .jpg from a xojo.net.HTTPSocket and am having a surprisingly hard time figuring out how to get its contents as a Xojo picture. Picture.open won’t work with the new framework folderItem. I’ve tried reading in the data as a binarystream and using picture.fromData, but that also doesn’t work with the new framework BinaryStream. I think I’m missing something quite simple…

For the data you get it shouldn’t make a difference if you use the old or the new framework. Why do you use a binarystream at all? Picture.fromData should work out of the box.

How does your code look like and what is your result? Do you get all the data for the picture?

I haven’t gotten it to compile yet. Picture.fromData requires a classic framework memoryblock. But to get the data in from the file (to read it into a memoryblock) you need to use xojo.core.memoryblock, which is not compatible. How else would you load the file contents into a memoryblock?

This is how I do it:

// mb is the Xojo.Core.MemoryBlock returned by the socket

dim mbTemp as MemoryBlock = mb.Data
dim p as Picture = Picture.FromData( mbTemp.StringValue( 0, mb.Size ) )

Aha, thanks, Kem. I was using only the FileReceived event. I need to use PageReceived for this. I’ll give that a go.

I think you can get away with just casting mb

[code]// mb is the Xojo.Core.MemoryBlock returned by the socket

dim p as Picture = Picture.FromData( MemoryBlock(mb) )[/code]

That throws an IllegalCastException: xojo.Core.MemoryBlock cannot be cast to MemoryBlock

Thanks Jonathan, I see that now :slight_smile: It compiles ok but exceptions when run.

I just tried this :

In a button :

Sub Action() Dim outputFile As Xojo.IO.FolderItem = Xojo.IO.SpecialFolder.Documents.Child("raspberryPi-Logo.png") mySocket.Send("GET", "https://www.xojo.com/images/raspberryPi-Logo.png", outputFile) End Sub

And in mySocket :

Sub FileReceived(URL as Text, HTTPStatus as Integer, File as xojo.IO.FolderItem) dim f as FolderItem = GetFolderItem(File.path, FolderItem.PathTypeNative) p = Picture.open(f) ImageWell1.Image = p End Sub

p is a picture property of the window.

Xojo.Net.HTTPSocket is asynchronous, so data may not be ready when you try to use it.

I think we need auto conversion for folderitem class and new core.io.folderitem.

Most of the classes need ‘bridging’ functions, the transition from the old framework to the new one should be gradual, rather than having dump out almost 20 years of code in one go.

Every time I try to use the new framework, I get frustrated by the incompatibilities. I should be able to update a single function at a time, where as right now, updating one function, requires updating everything else that uses it, then those functions and functions that use those functions, and this is all before I can test the one function that I wanted to update.

On a side note; these limitations are having a negative impact on Xojo. I recently spoke with a developer whom I was trying to persuade to use Xojo. When he found out that you need to use one framework for iOS and a different for desktop & web (he discovered this by reading the forums). He abandoned the idea and went with a competitors tool, for the simple reason he can use the same chunk of code for all supported platforms.

I’m certain it will change in the future, but for the moment the new framework is actually a negative for Xojo’s x-plat ability IMHO.

The ideas how Xojo wants us to convert to the new framework are naive at best. For those of us with big projects there is no way at all to convert such a project in one go (well except for the resident geniuses). We need to have transition methods, which likely will introduce new bugs.

Is there any progress with the new framework at all?

I know someone will frown, but I can’t shake the feeling that the new framework was a clever excuse for not being able to abstract the iOS framework into Xojo. Or fully implement controls methods and properties. I remember the beta back in December 2014 when I discovered, sometimes in horror, the incredible poverty of controls in iOS, for instance no button pointerDown/PointerUp or TextSize and TextFont. And everything is like that. Unfinished. In spite of the other clever excuse of protecting programmers from themselves.

After completing XojoiOSWrapper in a few hours, so again Val and Str among dozens others be accessible to existing code, I wondered why a company that so often insists on not breaking legacy, decided to create a new language instead of decently support the language. I came to the conclusion that whoever developed iOS simply did not feel like adhering to what had made the success of Xojo. Kind of like “it’s not fun” attitude. To hell with those pesky users and their old fashion RB syntax. Once again, what looks like a solid amount of nonchalance wrapped in a disconcerting contemptuous attitude for all those who had supported Xojo for over a decade. Now people who want to develop for iOS end up with incomplete features, limited controls, and the need for an awful amount of declares. NOT FUN FOR USERS :confused:

Exactly what I thought too.
Im just amazed (and worried) that Xojo want to roll it out in the other direction.
On that day, I will simply stop upgrading, and continue on with an old version until it no longer produces code supported by the OS.
It gives me no satisfaction to say that it seems every release brings changes which actually seem to make it harder and less pleasant for me to use the product , instead of improving the experience and lightening the load.
Example?: it’s taken me years to use the new IDE exclusively ( I needed the disc space) , but not a week goes by without me getting frustrated by it in some way.

Well, Real Studio compiles things fine for Win 10 as far as my needs go, so I thankfully can get by without the ghastly “new” IDE and the “new framework” that appears to be a radical and unnecessary change of language that will affect everything whether you give a hoot for IOS or not. Xojo is cutting itself off from its RealBasic roots and losing its simplicity in the process. While playing lapdog to Apple who seem to care nothing for migration path engineering. If I want a new framework, I’ll be trying to learn something else I suppose.

I often said I happen to like the new IDE and Xojo in general, as compared to the old IDE. But what I also mentioned quite often is how I loved being able to pick code from over ten years ago, and run it with minimal change. That remains true for the very latest version that lets me support HiDPI in Desktop without unnecessary tears.

That elegance, and respect of the user, probably got me spoiled, but it makes it even less tolerable to deal with an iOS product where the language has been thrown away together with a general “let them eat cake” attitude, where the smallest question about why, is met like adults talking to children. Compile that with a total absence of response to feature requests, the picture is not pretty.

Learning a new language for learning a new language, I might as well embrace Xcode which IDE is not that alien, and benefit from a really complete development tool. At least I will not have to beg anytime I need a feature that any user will expect on an average iOS app.

I’ve been arguing most of the points presented here since before the new framework was even announced, but this point right here is probably the most important.

Xojo did not need to give users an excuse to switch development tools, and that’s exactly what they did. If you need to rewrite your project anyway, why not explore another tool. For those that target Mac only (for example) wouldn’t it present a perfect opportunity to switch to Xcode?

The new framework is completely uninterested in legacy projects. Converting is so involved that old projects will never be updated. And the classic framework will eventually go away, leaving those projects behind.

I have yet to be convinced that the new framework was a good, or even necessary, idea. It was easier on the Xojo team, and we’ll pay the price for it.

Indeed. Without legacy, I have absolutely no reason to stay stuck with a half baked tool.

Exactly my point. Instead of taking the time and making the effort to completely implement the language, they invented what looks in fact as a shortcut to avoid work.

Rarely in the history of software, not respecting the user base has paid off. On the contrary. Among the historical examples, now long defunct WordStar died in part because it left behind with WordStar 2000 all that had made the product famous.

The timing is unfortunate, I don’t think for one moment that Xojo would make an intentional move to alienate existing customers, especially at a time when the 3 major platform vendors are all publicly making inroads in Xojo’s market space.

I’m sure that there’s plenty of good reasons for the new framework, I’m not debating that. I would like to see the transition as a gradual process, rather than cut and dry.