From Xojo’s forums where no one has bothered to answer that _could_ answer
Container Control Init
Should Container Controls be receiving set calls on computed properties before the open event fires?
Yes. When Xojo creates the layout that contains the container it effectively sets EVERY property regardless. Its as if you wrote :
dim c as new ContainerControl
c.property = value
c.property = value
... and so one for EVERY property ...
and now the Open Event can be raised
Setting left/right margins to 0
I am trying to add “MarginLeft=0” and “MarginRight=0” to the setupstring. I have settings=ps.SetupString and can dump the values in settings but the margins are not setup by default so I want to force it.
I’ve searched for a while but cannot find a way to add those two entries.
In general no you cant / shouldnt try to stuff values in there manually as this “string” is not meant to always be human readable to modifiable like this. MBS has plugins for Windows & MacOS that will permit you to control this in greater depth
On the forum theres a long thread about altering how the points in Feedback work and how they can be assigned.
I have to admit that from my perspective, and seemingly from others, the issue is not so much with gathering reports, but the “processes” that occur after gathering reports.
Currently we can assign points to reports by making them favourites. This at least indicates the 5 items each person considers high priority. And because more points go to higher priced licenses it also gives people who hold Pro and Pro+ licenses more influence when they do select a case to be a favourite.
Xojo frequently says that feedback is NOT the only criteria they use. They also consider the scope of the issue. I’m not sure how they assess this though.
Isn’t that what a lot of users making a case one of their top 5 cases _should_ indicate already ?
Even if the points system is overhauled does that changes the internal processes they have around Feedback ?
What priority _should_ a bug that causes a reproducible crash have – whether it has points assigned or not ? Or an exception that causes the IDE to lose whatever it is you’ve been working on ?
It would seem to me that those kinds of nicely reproducible bugs that cause fatal problems should have high priority regardless of how many points they have.
I’d think the KIND of case matters – sometimes more than how many points it has.
As Thom said on that thread
That’s where I think Feedback’s effort needs to be. The human element. Not to say the technical element is perfect, of course.
Buried away on the advanced tab of the inspector for most things is a little section that has a lot of check boxes labelled Desktop, Web, Console, iOS that I’m sure most folks dont know what they are for or what you’d use them for.
For your own code these can be immensely useful. If you happen to want to share code between project of different kids then you may need to use these.
What they let you do is create classes or code that can have different implementations depending on what kind of project the code is in.
For instance suppose you have a library of code you were working on, your own “framework” for an app that had aspects that ran on all targets.
You might create a module for your framework code. And in there it could have several implementations of your crucial method, Foo() – one for each of console, web desktop and even iOS as follows
Public Sub Foo(param as string)
MsgBox "desktop foo !"
Public Sub Foo(param as string)
MsgBox "Web foo !"
Public Sub Foo(param as string)
MsgBox "Console foo !"
Public Sub Foo(param as Text)
Dim helloMessage As New iOSMessageBox
HelloMessage.Title = "Hello"
HelloMessage.Message = "iOS foo !"
HelloMessage.Show // Not modal, so code does not pause here
Yeah I realize its not sophisticated. Thats not the point. Maybe this ias a method that you have for calculating some vital function for your app. Or for fetching some data from a web service.
The compatibility flags for each of these would be set differently. The one that sayd “Desktop foo” should be marked for desktop only
The web one would be marked for web only
And similarly for the iOS and Console one
So now we have this handy dandy super module with all kinds of functionality in it that …
yeah … this is an example OK ?
I have my module set up in a desktop application and if, in Window1.Open I put
Guess which method gets executed ?
If you guessed the one marked compatible with desktop apps then you’re quite right.
And if we take this handy dandy module and copy & paste it into a Console app, guess which one runs ?
And even iOS
Thats all well and good but whats going on ?
Is all this magic happening at runtime and all the code is in the app all the time ?
Not at all.
The IDE, at compile time, selects the compatible version of the methods to compile depending on how the compatibility flags are set. And it only compiles those.
So despite our handy dandy module having all those different versions in it only the desktop ones will get compiled in a desktop app, only the web ones in the web app, and so on.
No this isnt a rant about segregating developers into groups – maybe that will be a different post.
This is more about a couple recent conversations.
One had to do with how Xojo handles conversion & comparison of unsigned & signed values. Turns out that while I closed the bug report way back when based on info from a compiler engineer I now think that was the wrong move.
Citizen developers shouldn’t be expected to know, and usually don’t want to know, the arcana of why a 32 or 64 bit value compares to another using a specific x86 or x86_64 instruction that performs a bitwise comparison (which IS whats going on).
What they DO know is Xojo compares in a way that appears to them as really really wrong. The following code on 64-bit Mac and Windows, says “Value is greater than 0.” On 32-bit Mac and Windows, the message box says “Value is less than or equal to 0.”
Var Value As UInt32 = 4294967295
If Value <= 0 Then
MessageBox("Value is less than or equal to 0")
MessageBox("Value is greater than 0")
Thats not helpful and the explanation is truly arcane and relies on the bit wise representation of the values to explain why it appears so wrong. It might even explain some really erratic an unusual errors that people report that only occur once in a while.
The other issue that another user I was helping recently stumbled into was one I had never even thought about. If you create sql statement that uses prepared statements and dont provide as many bind variables as specified in the query then it can just silently do .. something.. which appears to vary depending on the database in use.
Again, this is not helpful and could quietly be doing harm by inserting bad data.
Thankfully this has been reported & fixed now(that no one noticed until now is a different issue)
But these two point out a specific problem. A citizen developers should be able to rely on the IDE and compiler to point out as many bugs and errors as early in the process as possible AND they should do “sensible” things.
Comparing what looks like a giant positive number and telling me its less than zero isnt sensible. Silently inserting nil instead of reporting a mismatch in the number of bind parameters isnt sensible.
Neither helps anyone, of any skill, write better more bug free code.
I’ve been poking about with some alternative tools – probably more than I have in the last decade or more.
Previously I’d look at them for “competitive intelligence” reasons. To see where they were, where they were going and what things they did better.
Now that focus has shifted entirely. I, like many others, have been looking at othertools with an eye towards maybe moving away from Xojo. Thats not likely to happen ASAP but there are some promising options I’ve looked at.
B4J is one.
Its visual designer behaves differently than Xojo’s but its not entirely foreign. And one thing you’;ll find different is that the B4J style of working is that you have to add references to controls & windows & the events they handle in a manner that is different than Xojo’s.
Its not better, or worse, just different.
Last night I sat and created a simple web browser app which in B4J took me about as long to create as it did in Xojo. Its really simple with a text field, a button, and an html viewer.
So that easy stuff just works – exactly as you’d expect.
Where the offset from REALPluginMain is an enormous value is VERY likely NOT correct that the call site was in REALPluginMain
So why does this happen ?
The system component that records the stack trace simply looks for symbols that are before the call site and reports those.
If symbols have been stripped then you see the problem. That crash logger cannot find the “correct” symbol and so may simply walk back a long long way to find one that hasnt been stripped. It reports that + a really large offset.