Recipe management software?

[GoodNPlenty]

Very Nice App, Thank You for all your hard work.

[Fangbeast]

Very Nice App, Thank You for all your hard work.

Thanks for that but it's still not quite working right in parts. Some of the control buttons stay in their 'pressed' state and there seems no reason for it.

Oh well, lots of things still have to be done.

[Keya]

im just wondering does your recipe software support 3D CAD models? lol i just read this... 3D-printed food creations coming to a Michelin star restaurant near you! http://www.bbc.co.uk/news/business-35631265
and the name of the 3D Printer he's using? Foodini ! looks like a microwave

[Fangbeast]

This is the full change log so far. And in all my tests, everything works except for the forms not responding if you mouse over it while importing masses of recipes.

I will see if I can fix that with a threaded model in the future. Still learning about those.

01/03/2016

Added: Copy selected ingredient to the clipboard
Added: Search current help page.
Added: Dummy help pages, nothing in them, that's your job!
Added: Launch home page to something user stores in Program\Homepage variable.
Added: All code that has yet to be done is marked as TODO or commented where possible.
Added: Delete ingredient from recipe. How on earth did I forget this?
Added: Shortcuts for all windows that had control buttons.
Added: Keyboard shortcut short text and long text for all shortcuts.
Added: Event section for all keyboard shortcuts.

Changed: 2 column names in database options table were changed because they made me forget what they were. Sorry!
Changed: LaunchBangFeast was meant to be LaunchHomePage.

Fixed: Category item count is updated after saving an recipe.
Fixed: Ingredient window didn't re-enable the data window. Bugger!
Fixed: Help window control buttons stayed in pressed state. Guess what I forgot to do!!
Fixed: Statusbar tooltip was missing the heading for the tip.
Fixed: Wordwrap missing from help screen.
Fixed: Search shortcut missing from help screen.
Fixed: All statusbar tips had to be checked.

ToDo 1. Way to much! (I don't feel the force today)
2. Keyboard shortcuts list
3. Create and manage a shopping list of ingredients for each recipe
4. Load instructions from a text file on disk.
5. Create an advanced searching window.
6. Print help pages.
7. Need a print button for the shopping list window

Bugs: 1. Funny issue with some form buttons stuck in their pressed state???
1. Search selects everything in the help form, not just the selected characters

29/02/2016

Added: Setup module with options.
Added: Escape and exit shortcuts for all windows.
Fixed: 23 values for 24 columns prevented recipe saving.

28/02/2016

Added: Show all selected recipes when export form is opened.
Added: Search from export form for recipes to select.
Added: Double click on recipe in export list to mark it as selected. (Persistent)
Added: Button to show selected records only in the export list.
Added: Export to XML file of selected recipes.

Hopefully, this link is still okay.

https://www.dropbox.com/s/s9yk29jr0fuhl ... es.7z?dl=0

Uploading the changes with a compiled EXE in case not everyone is running the latest PB as well as a database of nearly 5,000 Living CookBook recipes.

Upload should be ready in ten minutes.

[GoodNPlenty]

Download link works great, Thank You for the updates.

[jack]

hello GoodNPlenty
I think you jumped the gun too soon, wait a few more minutes because the file you got is 3 days old.
Hi Fangbeast
that's big update

[GoodNPlenty]

You are correct, I just noticed.

[Fangbeast]

hello GoodNPlenty
I think you jumped the gun too soon, wait a few more minutes because the file you got is 3 days old.
Hi Fangbeast
that's big update

Hope it's okay. Going to fix all the little things before I add anything else.

Wanted to add in an ingredients shopping module but it got a bit complicated so I want to clean all this up first.

[Fangbeast]

Folks, I am a little bit stuck as it's 26 degrees inside the house (Yikes!!), 38 outside and my brains are melting through my nose.

I've managed to speed up the display on start with transaction statements, works even for database queries but even using:

LockWindowUpdate_(WindowID(#Window_Recipes))

or

SendMessage_(GadgetID(#Gadget_Recipes_Recipes), #WM_SETREDRAW, #False, 0)

I can't get the initial 'greying out' of the form to stop.

Tried putting the initial ShowCategory into a thread but PB came up with an error here "EventID = WaitWindowEvent()"

I can't make it any faster unless anyone has some ideas?

[srod]

Keep all GUI stuff out of the thread fangles. Get the thread to do the number crunching and/or data retrieval/processing etc. and leave the main program to work with the GUI. The thread can always use PostEvent() to send custom messages to the main program (there is a good example in PB's user manual). For example it could send a message so that your event loop knows it is safe to update a List control with data just retrieved by the thread etc.

Whilst the thread is running there is nothing stopping your main program's event loop from ignoring some (or all) user input. Or just disable some of the controls just before you start the thread. This way, the GUI will still refresh, but will limit the user interaction etc. whilst the thread does its stuff. Means that you will not have the GUI appear to freeze.

And, finally, make sure you set the threadsafe compiler switch.

[Fangbeast]

Keep all GUI stuff out of the thread fangles.

That's going to be a problem as the routine that shows a category of recipes on start (and the main culprit due to how many recipes it must retrieve) and user choice updates a stringgadget from the record. No idea at the moment how to separate that out.

The select statement below coupled with the BEGIN TRANSACTION statement gives me the best speed.

"SELECT * FROM Recipes WHERE "
"Categories = 'Chicken'"
"ORDER BY Recipetitle ASC"
"LIMIT 26"

If I remove that limit clause, the greying out begins as the database tries to load all records and the form doesn't come back until the form has finished populating.

How do I get the data retrieval code to be in a thread without calling the string gadget to update each time a record is retrieved?

The thread can always use PostEvent() to send custom messages to the main program (there is a good example in PB's user manual).

Don't really understand it.

And, finally, make sure you set the threadsafe compiler switch.

That's always set.

Thanks for trying to help.

[srod]

Maybe the following will help.

Instead of using PostEvent() - which would definitely be the best way, I use a couple of global variables to manage the communication between a thread and the main program.

We have the main program which sets up a couple of gadgets and a simple thread. The idea is to have the thread message the main program when it wants the main prog to update the string gadget. The thread makes no attempt to update the string gadget directly.

In this example the communication is one way (through a global variable) in that the thread sends messages to the main prog. There would be nothing stopping the main prog sending messages back to the thread using the same global variable (or a different one) or to even pause the thread if it needed etc.

Code: Select all

;PostEvent() would give the best solution. However...
;we use a couple of simple global variables instead.
  Global gMessageFromThread ;Informs the main program what to do.
  Global gDataFromThread    ;Used to hold some dummy data from the thread.
  
;The following constants are for convenience only.
;The global variable gMessageFromThread would assume one of the following values.
  Enumeration
    #threadMSG_DONOTHING
    #threadMSG_UPDATESTRINGGADGET
  EndEnumeration
  

Procedure myThread(Value)
  Repeat
    ;DATA PROCESSING.  GET DATA FROM SQLite etc.
    ;We simply increment the gDataFromThread variable and inform the main program that we have new data.
      gDataFromThread + 1
      ;Signal the main event loop through the gMEssageFromThread variable.
        gMessageFromThread = #threadMSG_UPDATESTRINGGADGET
    Delay(1000)
  ForEver
EndProcedure
  
OpenWindow(0, 200, 200, 200, 100, "PostEvent")
  TextGadget(0, 10, 10, 100, 20, "Thread running...")
  StringGadget(1, 10,  40, 180, 20, "")
  thread = CreateThread(@myThread(), 0)
  
  Repeat
    Event = WaitWindowEvent(100)  ;Notice the time limit. You can remove this if using PostEvent().
    ;Check thread message.
    If gMessageFromThread = #threadMSG_UPDATESTRINGGADGET
      SetGadgetText(1, Str(gDataFromThread))
      gMessageFromThread = #threadMSG_DONOTHING
    EndIf
  Until Event = #PB_Event_CloseWindow

If this is any use to you fangles then let me know when you have digested it and I will post an identical snippet using PostEvent() instead of globals.

[Keya]

here's my Win/Linux/OSX-friendly worker-thread-with-GUI demo using PostEvent signalling
the important thing is there are no GUI things at all within workerthread, just PostEvents to signal the main thread to do the GUI updates on its behalf. Windows seems to let us get away with msgboxes etc from within the workerthread but Linux and OSX don't like it at all!

Code: Select all

EnableExplicit

Enumeration #PB_Event_FirstCustomValue
  #UpdateProgress
  #UpdateFinished
EndEnumeration

Procedure workerthread(WndId)
  Protected progress = 0
  Repeat
    Delay (20) ;simulate some work
    progress + 1
    PostEvent(#UpdateProgress,WndId,#PB_Ignore,#PB_Ignore,progress)  ;send update msg
  Until progress => 100
  PostEvent(#UpdateFinished,WndId,#PB_Ignore,#PB_Ignore,0)           ;send finish msg
EndProcedure

OpenWindow(0, 0, 0, 640, 80, "Worker-Thread GUI Demo", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
ProgressBarGadget(1, 12, 30, 620, 20, 0, 100)
ButtonGadget(2, 1, 1, 50, 20, "Start")

Define Event
Repeat
  Event = WaitWindowEvent()
  Select Event
    Case #UpdateProgress  ;worker thread has signaled the main thread to update the progress
      SetGadgetState(1, EventData()) 
    Case #UpdateFinished
      MessageRequester("Done","Finished!")
    Case  #PB_Event_Gadget
      If EventGadget() = 2   ;Start button
          CreateThread(@workerthread(), WindowID(0))
      EndIf
  EndSelect
Until Event = #PB_Event_CloseWindow

[TI-994A]

...can't make it any faster unless anyone has some ideas?

Perhaps display a timer-based splash screen (about 2 to 3 seconds) to allow the main form to load?



The main window will remain invisible until the splash-window timer unhides it.

[Fangbeast]

If this is any use to you fangles then let me know when you have digested it and I will post an identical snippet using PostEvent() instead of globals.

What a silly comment!!! I haven't been able to progress this far without your help. I keep telling people I'm not much of a coder but more of an assembler of bits and bobs. You and others have provided me the means to make lots of interesting stuff (At least to me!!) that I can give back.

I won't rewrite the recipe program with your suggestions as it took me 6 months to get this far and I am afraid to break it. The hot weather is not letting up and I get very confused in the heat.

I will try your postevent suggestion for the next program that needs to be totally rewritten, in winter!!!