[APP] Tabuh - An Automated School Bell Software

Hiya folks,
AjiMundi here. My day job required me to look for an automated school bell app. I found some pretty decent ones but I find them either lack something, or priced above my allowed budget (which is pretty much non-existent). This lead me to consider building my own app. Since doing this project put my game project on hold, I figured if I can't tinker with my game project, at least I should gain some learning experience to further its development. Thus the decision to create the app in Stencyl.

Description:
Tabuh (final name TBD) is an automated school bell software. It is designed to be easily setup, with minimal hassle to get it up and running. Editing schedule is a simple matter of creating a day schedule with intuitive drag and drop design and assign it to a specific day. You can set up the day schedule for a single day, or use it for several days across the week. You can also arbitralily assign a special day schedule for a day, which will be used only on that special occasion but can also be made into permanent schedule with a simple click of a button.

Updates:
Latest progress and screenshot: http://community.stencyl.com/index.php/index.php?topic=43730.msg246479#msg246479

Implemented feature:

• Core functionalities (load/parse schedule, date time calculations, bell trigger)
• Tabular schedule display, interactible with focus, highlighting and text edit.

Progress Summary:
20150917:

• Child UI object generation can now run as intended.
• Functioning text input/edit.

20150912:

• Further work on dynamic table and generic revamps on codes.
• Got child UI object generation running, but bugged on subsequent recoding, so it's disabled ftm.

20150910:

• Managed to get preliminary dynamic table generation running.
• Ditched some codes for clock and info displays for improvements (current WIP codes disabled for now).

20150907:

• Moved date time codes to a reusable clock actor.
• Integrating a debug procedure. It's currently in code but would later add a debug interface (e.g. buttons to add/substract time components to speed up trigger conditions debug.

20150904:

• Core functionality is working. Program now parse and run schedule as intended.
• Tabular display for day schedule is broken, currently disabled on test compile while debug in progress.

20150902:

• Basic implementation of core functionalities (date-time processing, schedule data format, etc)
• Early schedule implementation  ran in debug mode (static pre-made source instead of user configured).
  
• Currently experimenting in creating reusable dynamic interface elements.

Wish me luck.

Progress Log, 20150904:

Managed to get all the core functionality in placed. However, the preliminary code I used to display the daily schedule is broken somewhat when I experimented with interactible tabular display, so I disabled it for now. For now, the progran simply displays the current time and the next bell schedule.

Screenshot attached.

Looks cool ! Interesting idea , I never saw something like this used with Stencyl.

Looks cool ! Interesting idea , I never saw something like this used with Stencyl.

Well, there's not much to look at right now, but thank you.
The core functionality of the program itself is actually quite trivial. What is difficult is the presentation. I am currently moving my interface codes from the primary handler to separate, reusable actors. It is currently part of an all-in-one behavior scene.

For my next iteration: I think I'm going to move the date time functionality to a watch/clock actor which would broadcast to every behaviour that would require a time update. The watch/clock actor would have it's own configurable display functions, e.g digital/analog clock and would be reusable to anyone, even those who do not really need the time update, but simply a way to display a clock on their app.

Progress Log, 20150906:

I moved all the clock/calendar functionality codes to an actor. This actor now can be deployed independently to other application that requires it. Application can get time updates in two ways:

• Have a scene behaviour with custom events named Global_TimeUpdate and Global_DateUpdate. The former would be called every seconds (or closest approximate of it) and the later will be called on the change of day.
• Have any behavior monitor update on game attribute called GV_TIMEUPDATE. This maybe less accurate depends on where you put the monitoring, but more accessible globally.

For now this actor would only display simple time readout consisting of name of the day, date, and time. But future version would include the abilities to customize what it would display, like how to format date (e.g. May 1st, '16, 1/5/2016, etc), displaying the time graphically (digital/analog watch animation). It may even go as far as displaying interactible full-fledged callendar, although this would probably be better as a separate actor.
But that is for the future. Right now I would be concentrating on creating the editable schedule display.
Screenshot attached.

Progress Log, 20150910:

Managed to get the schedule displaying table working. It is not yet pretty (no grid/color division) since I was focusing on getting the dimension calculation and drawing output right first. With the kinks worked out I can begin the work to make it look better (adjustable paddings, line widths, colored columns, etc) and then making it interactible.

The dynamic generation is shown in the two screenshot below. The first one is generated with fixed column width. The second one was calculated on the fly based on table contents. I got the second one simply by removing the variable that stored the fixed column widths.

There are still too much leftover rooms because I calculated the fixed width based on the character 'w' multiplied with width unit and use the same number for the dynamic width. I will update the calculation later with better algorithms. Also looking forward to streamline the code. For now, it's quite messy.

Progress Log, 20150912:

I revamped the schedule parsing code to be more efficient. I guess the more you learn about a program, the better it can serve you.
I'm also halfway through implementing table interactivity. I have cursor-based focusing and highlights for the moment. I also managed to make it generate a text edit object when a cell is clicked, but somewhere between revamping codes for the schedule, the text edit and some other stuffs, I broke something. So I disable them for now while I track the  bug down.

EDIT: Just realized that I forgot to tell GifCam to capture the cursor.  Ah, well.....

Progress Log, 20150917:

I can't get much progress, thanks to EA/Origin, who made Red Alert 2 free through their 'On The House' program.
I did managed to implement a couple of stuffs, though. Namely, I got the interactive table's cell edit working again. For now, it's only text input/edit. The next thing I'm going to do is implementing time edit and drop down list. Then, saving the edit to active schedule.

Animated screenshot below.

What did you use to edit cells, did you use Mdotedot behaviour or did you do your own ?

What did you use to edit cells, did you use Mdotedot behaviour or did you do your own ?

I created my own. The entire UI is actually driven by a single actor type. The table actor was created by the main scene behavior, and it spawns the text edit as a child UI actor, which is an instance of the same actor type that the table came from. I do it this way so I can use it in other apps simply by importing one actor. Basically, I am aiming on being able to create entire application UI from that one object. This caused a lot of headache in catching up on all the setup that could go wrong and kill the app, but I think it's a very good practice in using Stencyl. Otherwise, I would've simply used MS Visual Studio for a simple app like this.

Nice.  I'm also creating UI  with actors and I use events to activate them. For now,  I have just a scrollbar and other things that I don't know the name Planning to put on the forge one day ... when I'll have the whole kit.

do you use text fields ( i mean the class textFields, or did you make your own) for the cell fields  ? I noticed you have capital letters. if you type shift+letter , does the capital letter work ?

Sorry for all the questions, but I'll have a big part UI to do on my project  so I'm pretty interested

Nice.  I'm also creating UI  with actors and I use events to activate them. For now,  I have just a scrollbar and other things that I don't know the name Planning to put on the forge one day ... when I'll have the whole kit.

do you use text fields ( i mean the class textFields, or did you make your own) for the cell fields  ? I noticed you have capital letters. if you type shift+letter , does the capital letter work ?

Sorry for all the questions, but I'll have a big part UI to do on my project  so I'm pretty interested

As an exercise, I try to create the entire thing using only the blocks available to Stencyl. I did have to use a couple of 'code' blocks for things like indexes in nested loops (Stencyl got them confused at one point and I decided to simply 'code' them all), nulls, and empty string value. I also have to bite the bullet and use pure code to enumerate available fonts. Aside from that, though, it's all Stencyl blocks.

For the cell fields, I use Stencyl's 'Any Key' event. It works well enough with shifted letters, I simply passed the characters 'as is'. For now the only other keys it handles are Backspace and Enter, but I'm planning to expand it further to accept navigation keys, mid-string edit, etc. But that's in the future, along with *gasp* Menu bars. For now, I am concentrating on finishing up the data manipulation and saving part, make it look decent, etc.

I can share my current actor, if you like. The codes are kinda messy with many things need to be organized, optimized, and debugged. I have all sorts of experimental codes and have not yet implement full error handling and attribute fall backs.  But if you want to take a look....

I am always interested to see other codes. It's funny to see the different ways of thinking, and you can always learn something

@Yoplala: Bad news: I took a hiatus from developing this to get another job done, and I kinda lost track on the last code I put in, which broke the UI actor.   Currently reloading my last backup for comparison. I'll post the fixed code once it's done.
Note to self: never stop halfway through implementing experimental codes.