Resource forks and Xojo

I’m in the process of refactoring my large app for Xojo from RB. I see the warning that resource forks are deprecated (I have a few cursors that are based on this). I did modify them to use png images. Here’s the problem:

  1. my app is not yet Cocoa-ready so I have to compile for Carbon for now
  2. Carbon refuses to compile with resource fork-based cursors, even tho this is only ‘deprecated’

So unless I complete all the refactoring for Cocoa, I cannot use Xojo for Carbon ie. at all for my app. Is there another way?
P.

I know the pain and at first we were terrified at the thought of “Cocoa-ing” one of major apps. For us, we knew the day was coming. And with RB already releasing cocoa in beta form over a year ago, we had time to explore our options. In the end, we determined it would be easier for us just to rewrite the entire app form scratch. Doing so allows us to incorporate better code practices that we have learned and also to add in new features that just was t possible under Carbon.

I’m not saying your only option is to rewrite your app. Doing so is expensive and might not be feasible to some. I’m just saying that:

  1. You know your app is not Cocoa-ready, but you know it is where you want to be.
  2. Some parts of your app (resource fork-based cursors) does not work in Cocoa.

I’m not sure there is an easy way out. You just need to analyze what you currently have and either continue patching or inventing new ways around it, break off the pieces that don’t work and compartmentalize it for sanity purposes, or bite the bullet now and do what we did. In the end, it really boils down to code maintenance. We saw Xojo as an opportunity to both modernize our app and to simplify it for future maintenance purposes. YMMV.

Cursors… as in Mouse Cursor (as opposed to a Database Cursor) right?

16x16? if so, why not use XML based cursor descriptions… these work very well with both Carbon and Cocoa (there are lots of examples on the old RealStudio forum).

If NOT 16x16, then you will have to Cocoa-ize, in order to use the new Cursor Constructor Method… I just added this to one of my apps creating 24x24 color cursors with a class that emulates SYSTEM.CURSOR almost exactly.

Until you decide to go Cocoa, how about using a previous version of Xojo.

I don’t think i’m that far off Cocoa-happiness (mainly GUI stuff from threads as the only infractions).
Yes, 16 x 16 mouseCursors.
You mean xojo r1 DID compile resource-cursors? That may be the best interim option.

just tried xojoR1 and it too fails to compile resource cursors

Can you use XML cursor descriptions? I made a cursor editor a year or 2 ago that produces XMLed cursors but unlike what Dave said they only work in Carbon (just recently tested for another cursor thread).

In this app, it can also create cursors during runtime by writing to a resource-fork then opening that as a cursor, and this still works. So I’m not sure how your resource cursors are accessed, this code looks like…

[code] dim rf As ResourceFork = f.CreateResourceFork(RBCursorFileTypes.rbcursor) //create resource fork

dim m As MemoryBlock = getAsByteData //create data to put in fork

rf.AddResource(m.StringValue(0, m.Size), “CURS”, 222, “name”) //set it

dim mc As MouseCursor = rf.getCursor(222) //retrieve as cursor[/code]
Do you use getCursor to load them or is there some other mechanism?

You could convert the resource cursors to XML ones with a little hacking of my app, I think. Here’s an example on an XML cursor that only works for Carbon

and the project is still posted here :slight_smile:
http://home.comcast.net/~trochoid/mycursor0g2(rotate).xml.zip
for the 1 error: change “EditField” to “TextEdit”

I’m not clear though, i thought you said you had converted them to pngs and loaded with the newish constructor. Why do you need these resource cursors still?

Due to ResourceFork being deprecated, I simply wrote my own ResourceForkMBS class.

[quote=29340:@doofus]
I’m not clear though, i thought you said you had converted them to pngs and loaded with the newish constructor. Why do you need these resource cursors still?[/quote]

Because my app’s in transition. Yes I have the Cocoa png cursors, but the rest of the app is still not Cocoa ready, and it needs frequent tweaks to keep up with our continuously changing image analysis requirements. So I need a single source that can build for Carbon & Cocoa via a switch (so I can update the Carbon right away while working on the Cocoafication for the eventual permanent transition).
As it stands, if I make a jump to Xojo en masse, I cannot build for Carbon (because of this cursor issue), so if I make updates in the RB version, they are lost in the xojo version, etc…etc… And I cannot build for xojo/cocoa because the refactoring still needs a lot of attention, so I cannot use xojo until the app is largely refactored.

Christian’s ResourceForkMBS interim solution may be best, but I have to figure out how to use this and end up with a cursor. May be simple, I have to look into.

Thx all,
P.

Wrap the cursors in a module that will switch how they’re built, i.e.

[code]Module MyCursors

Protected Function ResizeTopRight() As MouseCursor

static curs As MouseCursor

if curs <> nil then return curs

#if TargetCarbon then

  curs = ResizeTopRightXMLCursor
  //or
  //curs = loadCursorFromResourceFork(theFile, theIndex)

#elseif TargetCocoa then

  curs = new MouseCursor(ResizeTopRightPNG, 8, 8)

#endif

return curs

End Function

End Module

//…
app.MouseCursor = MyCursors.ResizeTopRight[/code]

sure, that’s if I had XML cursors, which I don’t.

You can load them from your resource-forked files, that seems to still work as the live cursor updating feature of my editor relies on it. From the code above it’s something like

dim rf As ResourceFork = theFile.OpenResourceFork dim curs As MouseCursor = rf.getCursor(theIndex)

Or convert those resource cursors to XML and forget about forking. If I knew how your cursors are organized, I mean, all in 1 file, 1 per file, etc, I think it’d be easy to modify my app to loop over them and write the XML. hmmm… this routine will convert all CURS resources in the selected file into xml versions in the folder “Exported XML Cursors” created on the desktop.

[code]Sub Action()

dim f As FolderItem = GetOpenFolderItem("") //choose file with 16x16 2bit resource cursors

dim rf As ResourceFork = f.OpenResourceFork

dim cursCount As integer = rf.ResourceCount(“CURS”) //collect CURS names
dim cursNames() As String
for i As integer = 0 to cursCount - 1
cursNames.Append rf.ResourceName(“CURS”, i)
next

dim destFold As FolderItem = SpecialFolder.Desktop.Child(“Exported XML Cursors”) //create destination
destFold.CreateAsFolder

for i As integer = 0 to cursNames.Ubound //for each CURS resource

dim data As String = rf.GetNamedResource("CURS", cursNames(i))  //get the data

dim mycurs As new CursorModel //shove into a CursorModel
mycurs.setFromByteData(data)
mycurs.setName(cursNames(i))

dim fout As FolderItem = destFold.Child(cursNames(i) + ".xml") //write xml file
dim tos As TextOutputStream = TextOutputStream.Create(fout)
tos.Write CursorModel.fileWrite(Array(mycurs))
tos.close

next

End Sub[/code]

My problem is different, want to use Xojo, start with Carbon but resources are not supported anymore, I was using them to add AppleScript support, a AETE resource… real problem and it appears there is no solution… bad idea to drop resources that way, really bad idea, it make transition complex or imposible :-/

For what it’s worth, aete resources are deprecated and you should be using sdef files instead.

But I read sdef files are Cocoa only, right? At least it is what I understood from the Apple doc.

From the sounds of things, Carbon too:

Ok, I will try it then, thanks.

Tried it and it doesn’t work :frowning: … The dictionary is not recognized, the app is seen as not scriptable.