iOSView changing background color

Targets iOS
1

I totally missed this. Code from Stephane Pinel!

Put this in View.open

  ' ObjC Declare to get a ref to a class by its name
  Declare Function objc_getClass lib "/usr/lib/libobjc.dylib" (aClassName As CString) as Ptr
  ' Here is the corresponding Xojo call
  dim theUIColorClassRef As Ptr =  objc_getClass("UIColor")
  
  ' UIKit Declare to create a color object
  Declare Function decl_GetColorWithRGBA lib "UIKit" selector "colorWithRed:green:blue:alpha:" (UIColorClassRef As Ptr, red As Single, green As Single, blue As Single, alpha As Single) As Ptr
  ' Here is the corresponding Xojo call, where we create a flashy green color
  dim myUIColorObject As ptr = decl_GetColorWithRGBA(theUIColorClassRef, (33.0/255.0), (209.0/255.0), (57.0/255.0), 1.0)
  
  ' UIKit Declare to get a reference to a View from its ViewController
  Declare Function decl_GetView lib "UIKit" selector "view" (aUIViewController As Ptr) As Ptr
  ' Here is the corresponding Xojo call (View.Self returns a ViewController)
  dim myViewPtr As Ptr = decl_GetView(self.Handle)
  
  ' UIKit Declare to set the backgound color of a View
  Declare Sub decl_SetBackgroundColor lib "UIKit" selector "setBackgroundColor:" (aUIView As Ptr, aUIColor As Ptr)
  ' Here is the corresponding Xojo call
  decl_SetBackgroundColor(myViewPtr, myUIColorObject)
2

Richard, this is brilliant !

3

That’s ok, don’t mention it :wink:

4

Hi Richard Berglund,
I have been looking for a way to do this for weeks.

Thank You!
JMW

5

Can this be applied to TextAreas and Tables?

6

Put this in the open event of a TextArea or a Table (or any other UIView-based control:

[code] Declare Function NSClassFromString Lib “Foundation” (className As CFStringRef) As Ptr
Declare Function colorWithRGBA Lib “UIKit” Selector “colorWithRed:green:blue:alpha:” ( _
UIColorClassRef As Ptr, red As CGFloat, green As CGFloat, blue As CGFloat, alpha As CGFloat) As Ptr
Declare Function view Lib “UIKit” Selector “view” (UIViewController As Ptr) As Ptr
Declare Sub setBackgroundColor Lib “UIKit” Selector “setBackgroundColor:” (UIView As Ptr, UIColor As Ptr)

Dim UIColorClassPtr As Ptr = NSClassFromString(“UIColor”)
Dim colorPtr As ptr = colorWithRGBA(UIColorClassPtr, (33 / 255), (209 / 255), (57 / 255), 1)
Dim viewPtr As Ptr = Me.Handle
setBackgroundColor(viewPtr, colorPtr)[/code]

7

It doesn’t work on a iOSTextArea in a iOSContainerControl and used as iOSScrollableArea.
Could somebody help to resolve it?

10

That works well for the text area and table until you add an entry into the Table. The following adds white row information

Dim i As Integer
Dim cell As iOSTableCellData
Dim cellP As iOSTableCellData

Dim menuitem() As Text = Array(“Player1”,“Player2”)

NotesList.RemoveAll
NotesList.AddSection(“OPTIONS”)
For i = 0 To menuitem.Ubound
cell = NotesList.CreateCell
cell.Text = MenuItem(i)
cell.AccessoryType = iOSTableCellData.AccessoryTypes.Disclosure
select case i
case 0
cell.Image = Surficon1
case 1
cell.Image = Surficon2
end select
NotesList.AddRow(0, cell)

Next

11

probably because the TABLE is a “container” (generic term, not to be confused with the “container control”), and the Table Row/Cell is an object that is placed into that container. The TABLE has its background color (which you set), and the Row has ITS background color which you did not set and defaults to WHITE.

12

Ok that makes sense but I can’t see a background parameter only setTint

Dim rowcolor As color = color.RGBA(255, 255, 57,1)
noteslist.SetTintColor(rowcolor)

13

as has been said many times, “Xojo for iOS” is lacking many, many standard items, such as exposing often used control parameters such as background color, and even background image

14

It is not new : Xojo Web does not support the very common background image attribute either.

But for iOS, the issue is even more acute, as one would have hoped Xojo to simply implement the same properties as what is commonplace in Desktop. Unfortunately, together with a rather contemptuous attitude (we protect you from yourself), it seems Xojo has no intention whatsoever to honor any of the most simple and legitimate feature requests filed since late 2014 for properties and methods that are sorely needed.

I am now convinced there is simply no pilot on the iOS plane.

15

I don’t want to or need to “be protected from myself”… if the idea is to keep me from making mistakes, by not letting me do “anything” then how is one supposed to learn? I know I keep bring up “Swift”, but if it weren’t for the ability to make mistakes, and have to figure out what I did wrong, I would never have progressed down that learning curve at all. As it is, I am 75% complete with a fully functional syntax highlighting, full featured text editor (think UltraEdit or Notepad++) for the iPad and iPad Pro… and this project would be (no, IS) impossible to replicate in “Xojo for iOS” without it being 90% “declares”, as it has custom controls such as true drop down menus, file open/save dialog etc etc… Not to mention the central “TextControl” which is NOT based on either UITextView or UITextField

16

I think the rather preposterous pretends to protect us from ourselves is a clever excuse for a botched implementation.

Likewise, the mandatory new framework for iOS looks suspiciously like a sloppy, incomplete implementation. What hurt would it have done to keep the regular methods, for instance, or even only the dot notation for methods ? No, they had to systematically change everything.

As a matter of fact, it even looks like someone had a pet project without any regard for the Xojo environment, and created a monster without even making sure of the coherence with previous developments.

Sure, there are areas of the new framework that do bring improvements, such as sockets. And there are cases where it was simply impossible to maintain the old, such as synchronous sockets or message dialogs. But there are countless places where maintaining the familiar environment was possible, and they intently chose to make it different.

There are many very common properties that should have been a given, such as background color for views, textFields, TextArea, labels, tables, even buttons. Confer XCode, which is after all the reference when iOS is concerned. Why did they not even condescend exposing that very basic property which had been familiar since the RB days ? (probably before but I did not use it then). Same thing for events as elementary as MouseDown ; well, PointerDown, sorry.

It has been my hope from the beta testing time back in 2014 that Xojo would be amicable to rapidly expose common properties and events. Then we went into a two years radio silence and near death experience, until a miracle happened and we got new controls this mid year. But yet, the pile of requests went completely unanswered.

My strong feeling is that most Xojo engineers could not care less about iOS today. They have other concerns. It is also quite possible that the commercial target was an entire failure, and that Xojo iOS has reached the less than enviable status of quasi door stop. I cannot blame them. I have my own content of apps I thought were going to be killers, and which sell anecdotally. Then it makes all sense.

No need to complain the corpse does not move. Rather go for more vivid tools, if you really need to get work done.

17

Wow… Michel… WELL said… to be honest, I have slapped my hand many a time when I had started to craft a response that says almost exactly this…

What I find interesting… (and this is by NO means an affront to Ulrich or Jason)… but I find it interesting that these guys (and a few others) have managed to “make things” work within the “Xojo for iOS” environment, yet the needed functionality that they provide for the most part has not made it into a released Xojo product… and yet they charge as much for the iOS version as they do for full desktop.

My desktop license comes due in early 2017… and I’m pretty sure I will let it lapse (partially for financial reasons, as I’m still unemployed :frowning: , but seems the direction of the product has become muddled)

18

I suggested a while ago that Xojo acquire dtPlugins to incorporate into Xojo iOS. After all, they are quite nice and complete. And it is not as if Xojo did not already bundle plugins with his product.

iOSKit and iOSLib are sometimes unachieved, but yet, they have very solid parts that could indeed make Xojo iOS extremely attractive.

I am afraid as I said the level of interest for Xojo iOS is internally so low, add it probably a good measure of not invented here, and a pinch of misplaced pride (what, me, engineer, using those open source things ?). The house will forever remain a scaffolding with missing bolts. At an age where developers have no time for incomplete products and have choice, I am afraid Xojo iOS is promised for a marketing purgatory of starvation.

At any rate, Xojo’s 2 years demonstrated lack of ambition for iOS already shows they don’t even believe into it.

We can bet without major risk that Desktop will remain the core business. By the end of this year, HiDPI will be quite stable, 64 bit as well. That should carry you on for several years.

About financial : is it not time for you to place all your goodies in the MAS ? You would be surprised how much they can sell. I have products that do zero business direct, and yet sell very regularly there. It may bring in some spinach…

19

I have been searching (like all of us) for that “Next Best Thing”… And while revenue from iPhone/iPad sucks (I’ve made $50 in the last year on two apps :frowning: )… I am still ever hopeful, my current project as I mentioned in a “desktop like” text editor for the iPad… which will then have a companion for the desktop. Its not as full featured as something like UltraEdit, but then its going to be running on a bit of a lesser device . Originally it was just going to be a super simple editor to be the front end to an educational program to teach programming, but the scope kept growing and it (I think) will be a nice editor in its own right… And I will “probably” still add the programming language part as another product. (It will be more than “line based” BASIC, and not quite a full OOP language… and interpeted, not compiled)

20

What about the picture editor your had, as well as DS Lockbox, StarTrekDS and CalcDS ? Each of them would probably do much more than $50 in the MAS. All you need to do is put them on the shelf.

21

StarTrekDS is what made the $50
CalcDS has made zip… will $0.70
DSLockBox needs some work (mostly code-signing, which I can do now :slight_smile: … since Apple only requires ONE developer account), this is an OSX app (which I have sold a few dozen copies), the other two are iOS apps… I started making an iPad version of LockBox which I may work on again.
PaintDS sold quite well originally, but it is outdated (Carbon based), and needs a lot of work to bring it back to level, and it would have some very stiff competition today which it didn’t have back then

But I am impressed that you remembered some of those :slight_smile:

22

Sounds like you and Michel have been early adopters of IOS and quite disappointed with the rollout. I’m only new to IOS and like how quickly you can develop a prototype for simple concepts but the more I do the more I see what you are talking about.

Back to my original thread, can you colour row backgrounds (or make the row background transparent) also it was mentioned you can put an image in the background but I am not sure how that would be useful does anyone have a screen shot of that implemented ?