BinaryStream Class

Can anyone tell me what the advantage would be of placing this method in a BinaryStream class rather than a module and would the code be the same?

Var value As Integer
Var path As FolderItem = SpecialFolder.Desktop.Child (HCPrefsCurentFolderLocation_C)

If path.Exists = False Then path.CreateFolder

Var file As FolderItem = path.Child(fileName)

If file.Exists Then
Var BStream As BinaryStream =,False) 'Big Endian by default

If BStream <> Nil Then
// Read the whole binaryStream
value = BStream.readInt32
Rem Reopen and create file
Var BStream As BinaryStream = BinaryStream.Create(file,True) 'Big Endian by default
End If

Return value

My understanding is reading a file will block execution of the rest of the app wherever you put the code until the read is finished. From that point of view I imagine there is no difference. Since it’s only reading an int32 you wouldn’t notice any performance issue.

If you put it in a class you will of course have to instantiate the class to make it run and make sure the scope of the variable and method is set to Public if used from outside the class.

I guess this is the part I’m trying to understand. Why create extra steps, in this case, instantiate a class rather than just make a call to a module. I find it daunting to know when it’s an advantage to create a class such as the BinaryStream class. Just trying to get a grasp on XOJO.

No, if there’s no data waiting, the read returns with no data. You should wait until you get a DataAvailable event, and then do a ReadAll to get all the data.

Do this in a thread, then you can sleep the thread (or pause it), and have the event handler resume it. That way the UI is not blocked.

How you organise the structure of your app depends on how complex it is, whether you want to easily reuse your code in other contexts, the long term maintainability of separating data from business logic from user interface. If it’s just a simple app you might not be bothered with much of this. Modules provide a simple way to organise code which may be enough. However with classes you can do things like represent entities with one lot of code that has a number of copies running to represent multiple entities.

For example if you want to support multiple screens doing the same thing, you could instantiate multiple instances of the Window, which would allow a user to use each of them differently without you writing extra code to keep each window’s functions separate. It would be very hard doing that in a module which only executes one instance of your code when you run it. You would have to do a lot of tracking to see which Window the user was using and keeping their values separate, which would be a lot of housework code indeed.

That’s not required to get a single integer from a file. If there was a loop getting thousands and thousands of them then you might need to use threading. You might need to get them in lots in a thread because file I/O does cause blocking because it occupies the processor waiting for a hardware interrupt and there’s nothing Xojo can do about that. However for simple apps this is not going to be an issue.

That helps Eric. The program is complex but it is basically a sequential process of checking sensors and turning things on and off, over and over 24/7. My first write of this program was years ago with RB 4.5 and I felt I did not take advantage of object orientated programing. So I’m trying to do a rewrite to incorporate a USB interface, the new XOJO and better understand how to write code thinking in object terms. The learning curve is steep since RB 4.5.

Well I expect the learning curve will be worth it because you could use the same code in an object for each USB instance without risk of mixing things up between them. You can use shared methods and properties between instances although I never have needed to.

Okay, here is where I’m lacking. “same code in an object for each USB instance”. So far I’ve only used one serialconnection method to write to an open port. Why multiple instances? You and others have your head wrapped around the concept way better than me.

I’m no USB expert but what if you want to support multiple devices?
Instantiating an object representing your functionality for each USB instance could make it easier to code.
Might reduce a lot of housekeeping code tracking which USB device you are dealing with at a time.

Ugh, punt I guess. I do have a multitude of routines for writing to the serial port for different operations but once again even though I could put them in a class and create an insistence I still don’t find any advantage over just calling them directly from the app. If duplicating code is a issue I just create a reusable method. One day the light may dawn.

You can cycle through an array of objects BTW.

It may not provide advantage if the app only scans serial ports. But if you want to add different settings to different ports, add a layer of security for different users accessing the system over the Web, things might get harder to manage if you don’t represent these different entities as objects. Also you might not be able to reuse your user security code in another app because it would be intertwined with serial port management etc.

I do use a class full of arrays and do send that object to a window with a construct which is a warm and fuzzy for me. I almost feel accomplished doing that.


I think our posts crossed.
BTW = by the way.

Okay, I an understand that but there will be a lot of water under the bridge before I cover that issue. I know your just saying!

I have the same kind of discussion with my son. He uses objects for everything which sometimes makes his code harder to read without first understanding the object model. However he has a point when you can use objects to simplify your code:

User(strUserName).Port(intPortNumber).Settings.Frequency = 10000 is easy to code and easy to understand in five years time because you’ve set up your objects intuitively using them as properties of each other for example. It’s really up to you and how much up-front investment you would like to make.

1 Like

I know your right on this. Often I think the type of program I’m trying to write, being very sequential might not take advantage of oops as others might but I see extremely powerful programs out there using little code which is amazing. I guess I will have to study their code until I can get my head wrapped around how to incorporate it into my project. I only learned about enums yesterday so the curve is still steep.

1 Like

There’s nothing wrong with a good piece of procedural code where everything is right there for you from top to bottom. Only the young-uns find it hard to read because they can’t keep so many things in their head at once poor darlings. So I’m changing my wicked procedural ways because I want my code to last.

1 Like

Eric. I removed a menu bar from my project and drug another populated one in. I have lost association to the menu items so things like this no longer work. Do you know how to correct this?

I’m placing a check mark by this menu item.

HeatingSeason_Mode(HeatingSeason).Checked = True //Menu Item Checked

App.StartUpSequence, line 34
This item does not exist
HeatingSeason_Mode(HeatingSeason).Checked = True //Menu Item Checked