Application:Domestic Photo Database

[collectordave]

Hi

blue
The collision in preferences I had allready corrected again just not uploaded file to github. Now uploaded. Enumeration for preferences starts at 500 not 50 so conflict avoided.

Bisonte

Thanks for that tip will certainly be updateing my little apps with that!

Regards

cd

[collectordave]

Hi all

It seems we may have two versions going at the same time my fault as usual..

Instead of uploading a single file at a time to github I have now uploaded the whole project again including all the images used.

Same link as before.

Hope this resolves some of te problems!

Regards

cd

ps just noticed another question I am using PB5.6B6 soon to be B8 running under windows 7.0 same also on my macbook with whatever operating system that is. I switch between x64 and x86 to check it works on both as I have some friends still running Win XP on old computers.

[Blue]

Hello smart Bisonte.
Long time no talk.

To solve this and future collisions use the enumeration value like this :
...
So you don't must remember, what you set before

Sound suggestion, Bisonte, but it fails when you're breaking your very large code into modules.

The method you suggest is what I personally always use. But Modules present a different challenge. If you try to reference the last constant in Module A as the starting value in Module B, the compiler complains that it doesn't know that last constant. Of course, it also could simply be that I'm not doing things properly.

collectordave's code is all intelligently organized and abstracted with constants, but it breaks because on that constants problem in modules.

Update:
Just checked with a little test code and, indeed, the method you suggest, Bisonte, does not work with modules.

[Blue]

A short example showing a method that works well to avoid constant collisions with Modules

Code: Select all

EnableExplicit
Macro QQ
 "
EndMacro
Macro DebugN(n,txt=" ")
 Debug ";"+ txt +QQ n = QQ + Str((n))
EndMacro
Macro DebugN(n,txt$)
  Debug "; "
EndMacro
Macro Debugg
  Debug ""
EndMacro

;-. modOne
DeclareModule modOne
  Enumeration 9
    #totoA1
    #totoB1
    #last_in_module_1
  EndEnumeration
  DebugN(#totoA1, "modOne")
  DebugN(#totoB1, "modOne")
  DebugN(#last_in_module_1, "modOne")
EndDeclareModule

Module modOne
  Enumeration 
    #totoA
    #totoB
  EndEnumeration
  DebugN(#totoA, "modOne")
  DebugN(#totoB, "modOne")
EndModule
;.
;-. modTwo
Debugg
DeclareModule modTwo
  Enumeration modOne::#last_in_module_1 + 1
    #totoA2
    #totoB2
    #last_in_module_2
  EndEnumeration
  DebugN(#totoA2, "modTwo")
  DebugN(#totoB2, "modTwo")
  DebugN(#last_in_module_2, "modTwo")
EndDeclareModule

Module modTwo
  Enumeration 
    #totoA
    #totoB
  EndEnumeration
  DebugN(#totoA, "modTwo")
  DebugN(#totoB, "modTwo")
EndModule
;.
;-. modThree
Debugg
DeclareModule modThree
  Enumeration  modtwo::#last_in_module_2 + 1
    #totoA3
    #totoB3
    #last_in_module_3
  EndEnumeration
  DebugN(#totoA3, "modThree")
  DebugN(#totoB3, "modThree")
  DebugN(#last_in_module_3, "modThree")

EndDeclareModule

Module modThree
  Enumeration 
    #totoA
    #totoB
  EndEnumeration
  DebugN(#totoA, "modThree")
  DebugN(#totoB, "modThree")
EndModule
;.

UseModule  modOne
UseModule  modTwo
UseModule  modThree

OpenWindow(0, 100, 100, 200, 200, "PureBasic Window")
Repeat
Until WaitWindowEvent() = #PB_Event_CloseWindow

I wish there was a method to fold code sections in this forum.
It would greatly help reduce visual clutter.

[Blue]

[...]
have you tried the vectoricon designer?

If you mean the vectorIcons collection offered as a pbi file, yes, indeed.
And I think every program, yours included, would greatly benefit from using that.

If you're not sure how to properly integrate the icon collection within your app, let me know.
I wasn't, so i asked LittleJohn (father of the vectorIcons project) for an example.
He sent me a simple, but very clear, demo. Just brilliant, really.

Update:
Here's that short demo, somewhat modified by me :

Code: Select all

; ------------------------------------------------------------
; February 2017
;
;   handcrafted by LittleJohn after
;   ToolBar example from PureBasic Help File;
;   tested with PB 5.44 LTS x64 on Windows 10
;   tested with PB 5.6b8 x64 on Windows 10
;
; ------------------------------------------------------------

EnableExplicit

XIncludeFile <your path>"\vectoricons.pbi"

Enumeration
   #Add
   #Refresh
   #Delet
   #ZoomIn
   #ZoomOut
   #Quit
EndEnumeration

Define.i event, tbIconSize=16

If OpenWindow(0, 100, 200, 250, 200, "Vectoricons toolBar example", #PB_Window_SystemMenu | #PB_Window_SizeGadget) = 0
   MessageRequester("Fatal error", "Can't open main window.")
   End   
EndIf

If CreateToolBar(0, windowID(0))
   ToolBarImageButton(#Add, ImageID(VectorIcons::Add("", #PB_Any, tbIconSize, VectorIcons::#CSS_ForestGreen)))
   ToolBarToolTip(0, #Add, "Add")
   
   ToolBarImageButton(#Refresh, ImageID(VectorIcons::Refresh("", #PB_Any, tbIconSize, VectorIcons::#CSS_ForestGreen)))
   ToolBarToolTip(0, #Refresh, "Refresh")
   
   ToolBarImageButton(#Delet, ImageID(VectorIcons::Delete("", #PB_Any, tbIconSize, VectorIcons::#VI_GuardsmanRed)))
   ToolBarToolTip(0, #Delet, "Delete")
   
   ToolBarSeparator()
   
   ToolBarImageButton(#ZoomIn, ImageID(VectorIcons::ZoomIn("", #PB_Any, tbIconSize, VectorIcons::#CSS_Black)))
   ToolBarToolTip(0, #ZoomIn, "Zoom in")
   
   ToolBarImageButton(#ZoomOut, ImageID(VectorIcons::ZoomOut("", #PB_Any, tbIconSize, VectorIcons::#CSS_Black)))
   ToolBarToolTip(0, #ZoomOut, "Zoom out")
   ToolBarImageButton(#Quit, ImageID(VectorIcons::Quit("", #PB_Any, tbIconSize, VectorIcons::#CSS_Black)))
   ToolBarToolTip(0, #Quit, "Quit")
EndIf

If CreateMenu(0, windowID(0))
   MenuTitle("Project")
   MenuItem(#Add, "Add")
   MenuItem(#Refresh, "Refresh")
   MenuItem(#Delet, "Delete")
   
   MenuBar()
   
   MenuItem(#ZoomIn, "Zoom in")
   MenuItem(#ZoomOut, "Zoom out")
   ;HideMenu(0,1)
EndIf

Repeat
   event = WaitWindowEvent()
   Select event
      Case #PB_Event_CloseWindow : Break
      Case #PB_Event_Menu
         Debug "ToolBar or Menu ID: " + Str(EventMenu()) + "  " + GetMenuItemText(0,EventMenu())
   EndSelect
ForEver

Check how the icons get incorporated into the toolbar.
No more external icon files to keep track of, nor to binaryInclude.
As i said, simply brilliant and very practical.

[collectordave]

Hi blue

I mean the vectoricon designer project which allows you to use the vector library to create icons of your choice as .png files.

I do like the idea of including the vector icons directly into the code though!

Will look into that later.

Cheers

cd

[Blue]

Hello collectordave

I mean the vectoricon designer project which allows you to use the vector library to create icons of your choice as .png files.

Oh ! I saw that as more of a manager than a designer. You only actually save stuff that's provided ready-made for you. But I used it, and it works flawlessly.

I do like the idea of including the vector icons directly into the code though!

Yes, look into it. I think that's the smart way to go. Dynamic icon creation is hard to beat if you aim to keep your code as small and as flexible as possible.

BTW I did re-download your project's files. And, as you said, this latest version works right out of the box. Very good.

[Bisonte]

Hello smart Bisonte.
Long time no talk.

To solve this and future collisions use the enumeration value like this :
...
So you don't must remember, what you set before

Sound suggestion, Bisonte, but it fails when you're breaking your very large code into modules.

The method you suggest is what I personally always use. But Modules present a different challenge. If you try to reference the last constant in Module A as the starting value in Module B, the compiler complains that it doesn't know that last constant. Of course, it also could simply be that I'm not doing things properly.

collectordave's code is all intelligently organized and abstracted with constants, but it breaks because on that constants problem in modules.

Update:

Just checked with a little test code and, indeed, the method you suggest, Bisonte, does not work with modules.

It works if you use a "common" module that is declared on top of your code (the first included file or in the main file on top) :

Code: Select all

DeclareModule common
  Enumeration EnumWindows 1
  EndEnumeration
  Enumeration EnumGadgets 1
  EndEnumeration
  Enumeration EnumMenus 1
  EndEnumeration
  Enumeration EnumMenuItems 1
  EndEnumeration
  Enumeration EnumImages 1
  EndEnumeration
  Enumeration EnumFonts 1
  EndEnumeration
  Enumeration EnumEvents #PB_Event_FirstCustomValue
  EndEnumeration
  Enumeration EnumEventTypes #PB_EventType_FirstCustomValue
  EndEnumeration
EndDeclareModule
Module common
EndModule

DeclareModule MyMod1
  
  ; Here the clou ;)
  UseModule common
  ; A few windows
  Enumeration EnumWindows
    #First
    #Second
  EndEnumeration
  
EndDeclareModule
Module MyMod1
EndModule

DeclareModule MyMod2
  
  ; Here the clou ;)
  UseModule common
  ; A few windows
  Enumeration EnumWindows
    #Third
  EndEnumeration
  
EndDeclareModule
Module MyMod2
EndModule

Debug MyMod1::#Second ; 2
Debug MyMod2::#Third ;  3

[Blue]

It works if you use a "common" module that is declared on top of your code (the first included file or in the main file on top) :

Yesss... I had completely forgotten about the "common" module concept.
Normal; I'm at this time in my life when memory has to re-defined as the faculty to forget.
Thanks for the reminder. I'll try it... if I remember.
I think the way we have to work with constants in modules is a bit cumbersome.
As are a few other things, like, for instance, having to enableExplicit for each single module.

[..]

Code: Select all

  ; Here the clou ;) 

Very funny, Bisonte. And your best code yet !

[Bisonte]

And your best code yet !

Oh no.... The initiation of this came from our Code Commander TS-Soft

[Blue]

@Bisonte,
you make me word too hard !

You're forcing me to revisit my understanding of constants,
but I finally figured out that

Code: Select all

  Enumeration EnumWindows 1
  EndEnumeration

is a VARIABLE NAME given to the enumeration, NOT just a starting value.

No wonder I agonized so much over constants in modules :
I totally misunderstood the nature of EnumWindows in the example you provided.
I thought it was strictly a starting value, like a constant, but it's not : it's a lot more than that.
It's the name of a variable identifying and associated with the specific enumeration.
That changes everything.

So, thanks for another push up the hill, Bisonte.
However, you must keep pushing; we're still quite a way from the summit.
Your work is not done yet.
And I'll sleep better tonight.

[collectordave]

Hi All

Just a bit about constants and enumerations and modules.

I have seen the problem before but simply worked around it.

Modules were created to be completly self contained. So variables and constants defined in modules were completly separate from other modules or the main programme. The problem arises as gadgets created in a module are not separate from the main programme so when a window or gadget is created with the same number as one allready displayed the first one disappears.

Now on the forum there are a lot of examples showing the use of enumerations to use constants for the creation of gadgets and I admit it seems an easy way to get a window up and running. So of course after trying it in a trivial way it all works. Then , as a newbie, you hit some problems and probably, as i did attempt to use a main module to hold all your constants or a header file with all your constants in, works great until you have a larger project where say you have twenty windows all of which display a button gadget for the user to click which says Ok. You want to create a constant #btnOk for each one, obvious then what you are referring to in your code. However trying to invent twenty different ways to say #btnOk soon becomes a chore.

So personally, I am moving away from enumerations for windows and gadgets and starting to define variables for each and use #PB_Any at creation time this means that in any module I can use the variable btnOk.i for my Ok button.

I do wonder if anyone else has found enumerations not to quite as usefull as first thought.

Regards

cd

[collectordave]

Hi

To illustrate the constant problem for any newbies like me here is a little code:-

Code: Select all

#MyFirstConstant = 154

DeclareModule App
  
  #MySecondConstant = 254
  
  Declare ConstCheck()
  
EndDeclareModule

Module App
  
  #MyThirdConstant = 354
  
  Procedure ConstCheck()
    
    ;Debug #MyFirstConstant
    Debug #MySecondConstant 
    Debug #MyThirdConstant 
    
  EndProcedure
  
EndModule

App::ConstCheck()

Debug App::#MySecondConstant 
;Debug App::#MyThirdConstant 

I have commented out some lines so it runs ok just uncomment the lines to see what happens with constants declared in different places in your code.

Regards

cd

[collectordave]

Hi

Another one for blue

blue wrote

You only actually save stuff that's provided ready-made for you.

Not quite! The vectoricon designer allows you to design your own icons. The ones in the database are ones I have "designed" based on Little Johns post. These are stored as drawing commands and can be scaled to suit.

Now the intriuging bit would be getting the vectoricondesigner to allow you to select icons and read these out as Procedures for inclusion in your programme as in your post above so only the icons you choose from the database are included in your programme.

Did that make sense?

Regards

cd

[Blue]

[...]
So personally, I am moving away from enumerations for windows and gadgets and starting to define variables for each[...]
I do wonder if anyone else has found enumerations not to quite as usefull as first thought.

Personally, i think that's going in the wrong direction.
Using variables for values that remain constant throughout the entire running of the application goes against the grain.

I've encountered the kinds of problems you mention, and i still find myself at times swearing at constants that seem to get in the way of my creative genius.
But i didnn't give up on them.
Don't either.

Rather, dig deeper into manipulating them and soon your mastery will improve.
In this current topic, just a few postings earlier, Bisonte has provided a very smart solution to manage constants across modules. Try his example code, work it, tweak it, test it, and soon constants in modules won't ever be a problem for you. If you don't care for his approach, look into the method, quite different from Bisonte's, which I have also provided with a sample code. It may appeal to you more, because it's simpler (i.e. not so smart ). But it also works very well across various modules. Again, try the sample code, tweak it, test it, and who knows ? You may end up adopting it.

Well, you asked for opinions. There you are then: that's mine.

Blue