Video page is empty for me :/

It is uploaded there and is supposed to be public but I can't see it when I try to either (unless logged in as me).

I'm just uploading it to youtube as we speak so it should be there in half an hour or so......

Version 0.11 of library now available with addition of progress bar and a demonstration video (see post 1)

[To do:]

To do:


Hardware

SDcard integration
Hardware RTC integration


Objects (these are all to be added but just what I've thought of so far):

Progress bar (vertical and horizontal)
Rev counter (like a progress bar but looking like a car rev counter)
Cyclebutton using an array of Strings.
ButtonLED  (like a check box but looks like an LED being switched on and off)
LED (like the above Button LED but just as an output)
StringBox  (Box containing text)


Shapes

needs quite a few adding
plus transform function to rotate a shape


Functions

modify AddImage to work with data and SDcard files as well as files in the EEPROM.
finish CycleBox in order to use more options allowing the cycling text to be formatted to the user's preference.


General

add more colours
make sure everything is in the keywords.txt file
finish manual
add more clock options
add more formatting options for objects
add calibrate function (allowing you to add a calibrate option to your program which will store the values on EEPROM/SDcard etc)  this will take into account the accuracy and sweep range

Here is an example of creating a screen:

This screen displays four cycle buttons and four check boxes plus a button to return to the main menu...

Code:

  if (DueGUI_currentlyDisplayedScreen==fan_screen){
    Serial.println("Setup: fan_screen");
    btnFBspeed0=DueGUI.addCycleButton(300,100,249,50,clrBlue,clrWhite ,clrWhite,clrRed,clrWhite,2,"Speed",20,posCentre,BVS_28,valFBspeed[0],0,9000,500,75,0,optVisible,URNnull);
    btnFBspeed1=DueGUI.addCycleButton(300,175,249,50,clrBlue,clrWhite ,clrWhite,clrRed,clrWhite,2,"Speed",20,posCentre,BVS_28,valFBspeed[1],0,9000,500,75,0,optVisible,URNnull);
    btnFBspeed2=DueGUI.addCycleButton(300,250,249,50,clrBlue,clrWhite ,clrWhite,clrRed,clrWhite,2,"Speed",20,posCentre,BVS_28,valFBspeed[2],0,9000,500,75,0,optVisible,URNnull);
    btnFBspeed3=DueGUI.addCycleButton(300,325,249,50,clrBlue,clrWhite ,clrWhite,clrRed,clrWhite,2,"Speed",20,posCentre,BVS_28,valFBspeed[3],0,9000,500,75,0,optVisible,URNnull);
    btnFBonoff0=DueGUI.addCheckBox(50,100,199,50,clrBlue,clrWhite ,clrWhite,clrRed,clrWhite,2,"Fan on",20,posCentre,BVS_28,valFBonoff[0],cycCHECKBOX,optVisible,URNnull);
    btnFBonoff1=DueGUI.addCheckBox(50,175,199,50,clrBlue,clrWhite ,clrWhite,clrRed,clrWhite,2,"Fan on",20,posCentre,BVS_28,valFBonoff[1],cycCHECKBOX,optVisible,URNnull);
    btnFBonoff2=DueGUI.addCheckBox(50,250,199,50,clrBlue,clrWhite ,clrWhite,clrRed,clrWhite,2,"Fan on",20,posCentre,BVS_28,valFBonoff[2],cycCHECKBOX,optVisible,URNnull);
    btnFBonoff3=DueGUI.addCheckBox(50,325,199,50,clrBlue,clrWhite ,clrWhite,clrRed,clrWhite,2,"Fan on",20,posCentre,BVS_28,valFBonoff[3],cycCHECKBOX,optVisible,URNnull);
    DueGUI.addButton(600,400,150,50,clrBlue,clrWhite,clrWhite,clrRed,clrWhite,2,"Main Menu",20,posCentre,BVS_28,optVisible,URNFBmainmenu);
    // Change the text in the header panel
    DueGUI.GUIobject_top[pnlTitle]="Fan  Screen";
  }

it requires a small amount of setup in the variables section as well:

Code:

//
// Fan screen
//
// setup the fan screen's screen number definition:
#define fan_screen 2
//
//
// The following line could be byte types but they are basically variables to store the object's object number.  This is purely to make things easier, you don't actually have to remember the object's number in a variable you can get the object's number from the URN using the function "findObjectByURL(URNname);".
//
int btnFBonoff0,btnFBspeed0,btnFBonoff1,btnFBspeed1,btnFBonoff2,btnFBspeed2,btnFBonoff3,btnFBspeed3;
//
//
// Here we actually setup a URN for the main menu return button.  The number can be anything that fits in an integer but for ease I will be using numbers 100-199 for the main menu (screen 1), 200-299 for screen 2 etc etc
//
#define URNFBmainmenu 209
//
//
// Here we setup the arrays used to store the values of the objects starting with the defaults.
//
int valFBspeed[] = {4000,3000,500,0};
boolean valFBonoff[] = {true,false,false,true};

As the user clicks the main menu button you need to save the values of the inputs back to the arrays:

The following is added to the on button event function.  You can see the URN is being checked and it is the URN defined above.

Code:

  if (URN==URNFBmainmenu){
    // Grab the data BEFORE you switch screens.
    //
    // Note the objects were created in order so we know that btnFBonoff1 is 1 more than btnFBonoff0 etc.  We can use this
    // to calculate object values in order to place in loops etc.
    //
    // store the values of the cycBoxes in variables ready to use again later
    for (int i = 0; i < 4; i++){
      valFBspeed[i]=DueGUI.returnIntValue(btnFBspeed0+i);
      valFBonoff[i]=DueGUI.returnBoolValue(btnFBonoff0+i);
    }
    printvariables();
    DueGUI_createScreen(main_menu);
  }

I hope it comes over as very simple to follow...

This is the basic program, all this one does is create a single screen called main_menu, a panel displayed on all screens:

A full demo showing the objects in action is in the download.

Code:

//////////////////////////////////////////////////////////////////////////////////////////
//                          Due GUI Object demonstration sketch
//////////////////////////////////////////////////////////////////////////////////////////
//
//  (c) 2013 Darren Hill (Cowasaki)
//
//  Version 0.10
//
//  This program is not as yet complete.  There are a number of missing features and features not fully implemented.
//  There is also the possibility that anything implemented in this pre-release version may be implemented in a different
//  way in any subsequent version
//
//  Many thanks to those persons that created the original UTFT library - Henning
//
// BASIC PROGRAM.



//////////////////////////////////////////////////////////////////////////////////////////
//                          Setup and initialise DUEGUI
//////////////////////////////////////////////////////////////////////////////////////////
//
#include <DUEGUI.h>
DUEGUI DueGUI(CTE70);   // which is: DUEGUI TFT1(CTE70,25,26,27,28);

//////////////////////////////////////////////////////////////////////////////////////////
//                          Setup for the external RTC library
//////////////////////////////////////////////////////////////////////////////////////////
//
#include <rtc_clock.h>
RTC_clock rtc_clock(RC);
char* daynames[]={"Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun"};
int hh,mm,ss,dow,dd,mon,yyyy;

//////////////////////////////////////////////////////////////////////////////////////////
//                          Setup variables for Due GUI
//////////////////////////////////////////////////////////////////////////////////////////
//

// variables for screens etc
int DueGUI_currentlyDisplayedScreen=0;
#define URNnull 0

// Every screen
int pnlTitle;

//
// Main menu screen
#define main_menu 1

/
//////////////////////////////////////////////////////////////////////////////////////////
//                          Due GUI Interupt routine and variables
//////////////////////////////////////////////////////////////////////////////////////////
//
// fast ticks for Due GUI interupt
volatile int l;
volatile int btnFound;
//
//  DueGUI Interupt handler routine
//
void DueGUI_tickHandler(){
  //
  // We don't want timer called whilst it's being handled.
  //
  DueGUI.stopTimer(DueGUI_timer);
  //
  // routine is called several times per second ie "ticksPerSecond".
  // l is incremented each time and by checking this against "ticksPerSecond"
  // we can make sure that once a second events are only called once per second.
  //
  l+=1;
  //
  // This is the "once per second" event routine.
  //
  if (l==ticksPerSecond){
    // second passed
    l=0;
    if (DueGUI.anyClockVisible) {
      rtc_clock.get_time(&hh,&mm,&ss);
      rtc_clock.get_date(&dow,&yyyy,&mon,&dd);
      //
      // Insert below the set and redraw clock functions:
      //
      //  Clocks that are only shown on some screens
      
      if (DueGUI_currentlyDisplayedScreen==main_menu){  
      }
    }
  }
  
  if ((DueGUI.dataAvailable()==true) || (DueGUI.anyButtonPressed==true)){
    btnFound=DueGUI.checkAllButtons();
    if (btnFound!=-1){
      DueGUI_OnButtonPress(btnFound);
    }
  }
  
  // Ok interupt handler is finished.
  //
  TC_GetStatus(TC1, 0);
  DueGUI.restartTimer(DueGUI_timer);
}



//////////////////////////////////////////////////////////////////////////////////////////
//                          DueGUI On button press routine
//////////////////////////////////////////////////////////////////////////////////////////
//
void DueGUI_OnButtonPress(int btnFound){
//  Serial.print("Button found : ");
//  Serial.println(btnFound);
  //
  //  Find the URN of the button that was found.
  //
  int URN=DueGUI.GUIobject_UniqueReference[btnFound];


}

//////////////////////////////////////////////////////////////////////////////////////////
//                          DueGUI display a new screen
//////////////////////////////////////////////////////////////////////////////////////////
//
void DueGUI_createScreen(int screen){

  // First stop interupts whilst we build screen
  DueGUI.stopTimer(DueGUI_timer);

  // Set global variable to record which screen is in view
  DueGUI_currentlyDisplayedScreen=screen;

  // Clear all the data and the screen
  DueGUI.clearAllObjects();
  DueGUI.clrScr();
  
  // Setup anything that is on EVERY screen
  // NOTE: pnlTitle's text is left blank as it is filled in by each screens functions.
  pnlTitle=     DueGUI.addPanel(0,0,799,50,clrBlue,clrWhite,clrWhite,2,"",280,8,BVS_34,optVisible,URNnull);
  
  if (DueGUI_currentlyDisplayedScreen==main_menu){
    Serial.println("Setup: main_menu");
    DueGUI.GUIobject_top[pnlTitle]="Main  Menu";
  }


  // ok draw all the new objects that are supposed to be visible
  DueGUI.redrawAllObjects();
  // we can restart the interupts now
  DueGUI.restartTimer(DueGUI_timer);
};



//////////////////////////////////////////////////////////////////////////////////////////
//                          DueGUI demo setup() function
//////////////////////////////////////////////////////////////////////////////////////////
//
void setup(){
  //
  // Initialise serial on the programming port (this section is for debugging)....
  Serial.begin(115200); Serial.println("\n\nSERIAL CONNECTED AT 115200\n\n");

  //
  // Initialise for RTC
  rtc_clock.init(); rtc_clock.set_time(__TIME__); rtc_clock.set_date(__DATE__);
  
  //
  // Initialise DueGUI
  DueGUI.InitGUI(6,5,32,3,2,52,2,51);
  
  // Display "main_menu" screen
  DueGUI_createScreen(main_menu);
  
 }


//////////////////////////////////////////////////////////////////////////////////////////
//                          DueGUI demo loop() function
//////////////////////////////////////////////////////////////////////////////////////////
//
void loop(){
  // Do things here :-)
 
}

First version of the DueGUI library is now downloadable...


http://forum.arduino.cc/index.php?topic=164788.0

Ok....

This is an ALPHA test version but here is the first downloadable version with early manual:

www.cowasaki.co.uk/DueGUI/DueGUI_manual001.pdf

www.cowasaki.co.uk/DUEGUI_001.zip

Well I've had a useful day with the library.  There was a bug that was corrupting the variables and causing hours of wasted time but I've fixed it now!

Anyway new additions to the working objects list:

addInputBox !!!
drawInputBox
updateInputBox
updateLabel       (automates the sequence..  if variable has changed then remove old value,display new value, update object.
setColorLong           (these new colour commands allow setting of a colour using 1 long int in the form 0xFFFFFF where value is 0xRRGGBB
setBackColorLong          having it as one value makes it easy to have presets such as clrBlack,clrBlue,clrYellow etc)

This scrolls the screen up so that the object is visible in the top half of the screen and displays a keyboard at the bottom half of the screen.  The keyboard is definable with a caps key and a symbol key allowing 3 full 52 key keyboards.

So we are nearing the point where it is alpha testable.....

I need to write a manual for it first but as my code is very heavily remarked that will make it much easier.

There are still parts not finished but I will highlight those in the manual.....

Sorry, posting 5500+ lines of code would have been silly when this was more out of interest than anything else.  Someone was able to come up with the solution without the code.  I am more than happy to jump in and help others and usually the code is necessary but on this occasion it would have been ott.

I'm certain that it would have been possible to demonstrate the problem in considerably less than 5500 lines of code. Just the act of doing so would probably have been enough for you to spot the problem on your own. In any case, posting a minimal sketch that actually demonstrated the problem would have avoided relying on some inspired guesswork by majenko and would have avoided everyone else looking at this thread from wasting time trying to guess what you were doing. If you had posted a short sketch demonstrating the problem, it would have been blindingly obvious what was causing it.

I'm sorry but as I didn't know what was causing the problem it makes building a small sketch that recreates the problem quite difficult!

It just seemed odd really and knowing that interrupts stop delay() and millis() working would have made the process of finding the problem instant hence another member knowing what the likely issue was. 

Like I said, the library was never going to keep the delay in anyway so writing the rest of that function negated the need for it but I was curious as to why it was happening.


Anyway I now know what the issue is and anyone reading this will do too so it has been a useful excursion from what I am doing.

[could]

You're not using delay() or millis() from within an interrupt are you ...?

Yes, a slow one. Didn't know that was an issue but it does make sense thanks.

delay() checks the return value of millis() against a timeout value.  millis() returns the value of a counter variable.  That counter variable is updated once a millisecond by a timer driven interrupt routine.

That interrupt routine cannot run while you are in your interrupt routine, so the counter never increases.

Interrupt routines should be kept as short as possible so that other interrupts have a chance to fire.  The "proper" way of doing what you want is to set a flag (and maybe a couple of variables - x/y coordinates for example) in the interrupt routine, and then watch for that flag being set in the main loop.  Only in the main loop would you do slow and intensive operations like drawing widgets on a screen.

You need to separate the "capturing" of the event and the "reacting to" the event.  The capturing is done in the interrupt by setting a flag that says this event has happened.  The reacting to is done in the main loop by it realising that the event happened recently, so it does what is needed.  The capturing wants to be instant and reliable (interrupt) but the reacting to can be slightly delayed by a few milliseconds without any adverse consequences (and maybe not even being noticable) - the event has already been captured.

Thanks for your reply but I actually already understand all this anyway.  My interrupt handler is very short and uses its own interrupt on the Due (checked beforehand to make sure it was clear), if it detects an event it needs to deal with then it halts the interrupt whilst it updates the screen etc then restarts it.


Thanks to everyone who tried to help but majenko got it..


the only thing here I didn't realise was that delay() and millis() didn't work inside an interrupt. 

millis() could have been updated by another interrupt hence me trying to use the loop alternative myself to see if delay() was the issue.

It was only done like this as a quick kludge to check the display before connecting the process to the on button press and on button release events.

You're not using delay() or millis() from within an interrupt are you ...?

Yes, a slow one. Didn't know that was an issue but it does make sense thanks.

So you're starting to realize why most people ask you to post all of your code rather than just what you think is the problem?

Sorry, posting 5500+ lines of code would have been silly when this was more out of interest than anything else.  Someone was able to come up with the solution without the code.  I am more than happy to jump in and help others and usually the code is necessary but on this occasion it would have been ott.

I have a full qwerty keyboard with number pad very nearly finished. This will be for text input boxes. I am hoping that it will be in a fit state to go out for alpha testing within the week. There are dozens of functions added and a demo program which shows them in action. All the object orientated stuff works via an interrupt which is added by the library so you can even end up with the loop function empty! 

Anyway will update with more pictures etc soon.

You're not using delay() or millis() from within an interrupt are you ...?

Yes, a slow one. Didn't know that was an issue but it does make sense thanks.

The sketch stopped at the delay. Its all working now as the delay was only there as a temporary measure.

I just thought it a little strange.

The whole sketch compiles to 64k so probably a bit much listing it all

No it's not really part of my code at all! It was a quick hack to replace the delay() function to see why it was happening! 

I'm still writing it at the moment and it now works because I now change the key top colour until the user takes the stylus away then change it back so it is working without the delay bit.....  The delay bit was only there to test the colour bits and was never staying.  It just seemed weird that it would do that at all!