topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Monday March 18, 2024, 10:41 pm
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Last post Author Topic: Programming Question...  (Read 22447 times)

kfitting

  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 593
    • View Profile
    • Donate to Member
Programming Question...
« on: August 09, 2005, 01:44 PM »
What database backend are you using for CHS?  Also, how easy is it to manipulate?  We are looking for a quick and dirty database for keeping our wirelist info at work.  The one used in CHS looks very interesting. 

Kevin

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Programming Question...
« Reply #1 on: August 09, 2005, 01:57 PM »
im using dbisam, at least for now.
i have to tell you, i am not a fan of using databases in programs.  it has some advantages, but i've now done it in several programs, and there is no end to the pain involved (imho) in getting things to work right.
unless you are going to have 100,000 records, i would give serious thought in the future to whether i really wouldnt be better off with my own custom data structures.

kfitting

  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 593
    • View Profile
    • Donate to Member
Re: Programming Question...
« Reply #2 on: August 09, 2005, 02:05 PM »
Hmmmm... for us, Excel works fine, except that we now have over 40,000 wires in our trainer.  Excel gets unwieldy with that amount of data.  We were thinking about going to access, but there is too much programming involved. 

A quick thought... how easy would it be to make a basic database program?  Could this be a coding snack?  From looking at CHS, that level of functionality would be great, no fancy menus (although I guess you need to be able to edit the records somehow... double click to edit within the cell). 

- The ability to add and delete columns would be needed.
- Keep database info in ONE file
- Import/export to Excel would be a definite plus, almost a necessity

But, beyond that, CHS has about as much functionality as I'd want.  I've often wondered if there was a program like this out there.  Wow, I'm getting excited!

Kevin

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Programming Question...
« Reply #3 on: August 09, 2005, 02:11 PM »
there are some nice customizable easy-to-use personal database tools out there - i think chs may morph into one of those.
check this one out: http://www.brilliantdatabase.com/

kfitting

  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 593
    • View Profile
    • Donate to Member
Re: Programming Question...
« Reply #4 on: August 09, 2005, 03:31 PM »
I looked at brilliant, still trying it out.  The only thing is, it does so much!  I love how CHS' database view is clean and simple.  Basically, it's like Excel for data storage.  That's all I really want.  A little customization would be nice... but not necessary.  Make it import/export to excel and everything would be great!  You dont think you could tweak CHS' database code, throw it into a simple gui (one pane, a few menus) in a short amount of time?  How many people use Excel for data storage?  This would be the same concept, just able to handle larger data sets.

Just an idea.  I'm probably over-simplifying greatly.  Ahhhh... but dreaming is such fun.

Kevin

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Programming Question...
« Reply #5 on: August 09, 2005, 04:54 PM »
its not a bad idea -
adding and deleting columns is not so hard though its a bit tricky to get it to work cleanly.
but yeah i could make a minimalist single pane viewed db tool which lets you custom add the columns you want,
and import/export to excel..

not a bad idea - really minimal db editor..

let user create/delete columns, fill in data, import+export.. search, filter.

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Programming Question...
« Reply #6 on: August 09, 2005, 04:57 PM »
the real question is whether there isnt already nice tools for this..

kfitting

  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 593
    • View Profile
    • Donate to Member
Re: Programming Question...
« Reply #7 on: August 09, 2005, 05:07 PM »
Yeah... I've looked for some and havent found any.  Everyone seems to want full featured bloat (bloat relative to what I'm describing).  I don't know if I could use it at work due to government liscencing stuff, but I've often wanted something for keeping track of stuff around the house, keeping a list of pictures (yes I know there are programs for this!), etc.  But, I don't want to have to code to get it working.  It would be kind of cool to be able to write scripts for it, but that is NOT necessary. 

The only other feature I can think of other than what you just mentioned would be custom views, stored in the database file (so if you opened it up on another machine someone else could have the same views).  Each view could have a certain configuration of columns in it.  Forget forms, the way you have CHS allow you to group based on a certain column is incredible. 

Even scripting, if you could make it easy for AutoIt or AutoHotkey to grab info from the window (window control names, table handles, <I don't really know what I'm talking about here!>, etc) would allow scripting without a whole lot of work on your part. 

The only other thing, and I don't know a thing about databases, is that you should be able to edit a record like you edit a cell in Excel.  I personally think it's annoying to have to go to another textbox to fill in the data for a cell.  Maybe this isn't possible, I don't know how databases work.  I think you have it set up fine in CHS, since it's function is just to display pertinent data, not change it.  But for a program like this, it would be cool.

Give it a thought... if not, that's fine. 

Kevin


mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Programming Question...
« Reply #8 on: August 09, 2005, 05:17 PM »
its easy to make the data editable all from the grid.
scripting is probably quite a bit more work depending on what kind of information you want to make accessible.  if you elaborated on the kinds of scripts you might want to use it would help answer that.

your request that everything be in one file might be problematic - though you could get around it with a virtual file type system.
by far the easiest thing would simply be to change from saying a single file to a signle directory.

so your Wires database
would be
Wires\

and in that you would have database files, preset views, etc.

you could add functions for ziping and unziping if you really wanted to hold the users hand.

but relaxing the demand for a single file and make it a single directory would make everything easier.

kfitting

  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 593
    • View Profile
    • Donate to Member
Re: Programming Question...
« Reply #9 on: August 09, 2005, 06:07 PM »
Ok, point taken on the single files bit.  I think it would be better to hold the users hand on this one... only because our CM (configuration management) process doesn't make it real easy to keep multiple files together on check-in/check-out.  It would be much easier to just have one file for the user to manage.  But, multiple files would still work!

Scripting.  Let me give you the example that I feel is the most involved.  First some background:  in our flight simulator (the aircraft is the MH-60R for you aviation fans) we need to keep track of every wire along with various information (wire type, size, length, starting point, ending point, etc).  There are quite a few wires that connect to other wires and at times it's EXTREMELY handy to be able to enter in a node and find a trace of every wire along a route.  I.e. from a power supply to a specific light bulb in the cockpit.  Ok, don't lose me here, I know as an engineer I tend to get lost in details!  One of my coworkers wrote an excel vba script that, given any node, traces it back both ways to its end points (if you start at the beginning, it only goes one way, obviously).  This script saves valuable time when troubleshooting, especially when your wirelist is 40,000 lines plus.

Basically, it would be awesome to be able to interact with the data in that level of detail.  To be able to step through the table, make comparisons, keep a log in the background...  That's why if you could make the table accessible to AutoIt the problem would be solved.  I don't think it's worth writing your own scripting into the program, but making external hooks would be nice.  That way people could use the program to store the data, sort it, search it, but if they came up with some kooky odd-ball "requirement" they could add it on their own.

I know, I know, you're saying "why not just use a database."  Well, the biggest reason is none of our team has experience programming databases.  All we need is something light and fast to store lots of lines in and be able to write scripts to pull certain data out.  Database setup is too much work! especially mid-project)  Excel works fine except we have 40,000 lines and another 20,000+ waiting to be added!  Excel runs out of space and also becomes rather clunky.  But, having seen the power and awesome sort/grouping/filter capabilities of CHS, I think a minimalist database would be just the thing.  Also, like I said, I would love to have it for home use... keeping track of cd's, books, whatever.  Yes, I could use a database and spend umpteen hours coding each database I want to keep.  Yes, I could use one of the freeware solutions that do everything and the kitchen sink (all this in rather clunky interfaces with childish icons). 

But, having said all that I don't want to take up your time... especially since you're working on CHS and all it's goodies.  Plus, I realize that maybe this is a specialty app... but, oh how long I've looked for something like this!  If you could do it, I'd be absolutely thrilled.

Kevin




mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Programming Question...
« Reply #10 on: August 09, 2005, 06:31 PM »
let me finish work on chs first and then i can look at splitting off some code to a super simple database tool, but still considering the features that would be useful to you when working on chs.

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Programming Question...
« Reply #11 on: August 09, 2005, 06:44 PM »
yeah it does sound like you need a proper scripting interface..
i'll have to think about that.
it actually shouldnt be so hard to provide such an interface to allow such manipulation

i just can't help thinking there must be existing tools for this.
but then on the other hand, if i have 90% of the code written, what's another 10%.
unfortunately sometimes the 10% takes 90% of the time.. yipe.

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Programming Question...
« Reply #12 on: August 09, 2005, 06:48 PM »
so a question-
you wouldnt want any of the things that chs does to help working with data?
ie hierarchical groups, keeping track of modification + viewing date?
or would you?

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Programming Question...
« Reply #13 on: August 09, 2005, 07:03 PM »
i keep trying to think if its possible to merge chs with the functionality of a more general purpose db tool..

kfitting

  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 593
    • View Profile
    • Donate to Member
Re: Programming Question...
« Reply #14 on: August 09, 2005, 07:24 PM »
Wow... going nuts posting?!  Heh heh, let me try to answer these questions.  I agree, that the more general you make it, the better it will fit many people's needs.  With that in mind, here are my ideas:

- Viewing/Modifying date wouldn't be bad... they could just be a field in the table.  Same with other columns.  I would allow these to be customizable.  A database that is 100 meg that contains every piece of data under the sun isn't real helpful in my case, though it may be in someone elses.  Perhaps a quick interface to make columns that auto-update (date/time, computer login name, etc).

- A hierarchical tree isn't really necessary.  Not that I would complain if you included it, I just don't see how it would help under the circumstances.  I basically see a tree and database as two different ways to represent the same data.  If you could make the tree easily reflect the database... then maybe it would be useful.  (sorry, I'm going to brainstorm out loud... I may work myself into a contradiction).  Using filter nodes could have some uses... especially if you are using the database to keep track of objects around the home.  However, I think it should be thought of as the database influencing the tree rather than the tree imposing structure on the database.  SUMMARY: yeah, it might be nice to have a tree.  A mixture of filtered nodes and user defined nodes (user defined nodes would allow a user to drag a database record onto them, or multiple records at once) would allow you to keep search results handy for later use. 

Whooo... going in circles here! Perhaps a two pane view, tree and database, would work.  Actually, the tree might prove really useful since databases usually use forms to customize user interaction.  Nodes would allow user interaction but require no programming.  I can also see where they would allow you to set aside certain search results for later work.



Ok, in other words: I like your ideas.  So long as the main focal point is the database table itself, I think it will work real well.  Sorry I rambled, but that's how I think!  Any questions let me know. 

Kevin

kfitting

  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 593
    • View Profile
    • Donate to Member
Re: Programming Question...
« Reply #15 on: August 09, 2005, 07:42 PM »
The more I think about this, the more excited I get.  I can think of bunch of things I could use a program like this for.  From applications at work (personal database for parts, lists of all types) to uses at home (organizing collections).... wow.  Once again, a database would work, but databases require so much programming and setup time.  Besides there are lots of people that use Excel for storing data.  This would be (for data only!) a glorified Excel. 

Concerning trees: it would be kind of neat (though another level of complexity) to be able to have file specific nodes and user nodes.  File nodes would travel with the file.  In my scenario, amongst the team we could have certain nodes for certain parts of the trainer.  But, my user nodes would stay on my harddrive.  When I open the file, the program looks at the file nodes, then the user nodes and builds the tree from them.  This way I could make my own searches and have access to them without cloggin other people's views. 

Couple quick things:
- import/export to excel is key!  We must deliver our wirelist in a common format, plus people shouldn't have to reenter all their data.
- Minimal impact on the user's machine.  Registry keys should be avoided as much as possible, no-install version, etc.  Perhaps user ini files would work.

Man, I'm getting all excited about this.  Going to be hard to wait, but some things are worth waiting for.  Your the programmer!

Kevin

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Programming Question...
« Reply #16 on: August 09, 2005, 08:49 PM »
i avoid registry like the plague - i tend to keep all settings in ini files in the app directory for easy moving.

note that chs has current "virtual folders" which you can set up specifically to display virtual views of the data - the "Favorites" folder is just a virtual folder that says "show all data items not in recycle bin and with the favorites field set to true"

the "quick paste" virtual folder shows all items added in the last week.

so the idea of virtual folders is exactly as you say and easy to create virtual folders that save the results of past searches.  when i add more complex searching i will add a button to say "create a virtual folder from this search", which should make it even easier.

im not sure exactly your file and user nodes but i think we might be on same line of thinking.

right now, chs uses 1 database.
in that database are 2 tables, one for the items (clips) and one for the tree.  each item belongs to one node in the tree.  the tree nodes are arranged in a hierarchy.  all items in the table have the same fields (this is super important for later discussions).

one of the benefits of saying that each item(clip) in the database has same fields is that its easy to drag and drop and move items between nodes in the tree (groups), and it makes sense to do 2 things i really love:
1) have a recycle bin
2) have recursive display of items(clips), so if you click on "all" you see all records, etc.

so right now, chs works with one database, which it expects to be a in a specific format with a specific set of fields.

--

now
what would be interesting would be
if we added the ability for chs to manage multiple databases.

each database could be like a root node.
within each root node would be like a mini tree seen in current CHS view.

thse different databases would be automatically "discovered" by looking at subfolders in some directory.
so that merely copying in another database subdirectory would make that database available as a root node in the tree.

each database node could have its own set of columns, its own recycle bin, etc.
they would basically be independent databases with no interaction, but just be very easy to switch between, depending on what you wanted to work on at any given time.

there's something quite appealing about this, but my main concern is writing something like this, a very general tool, without too much attention on what it would actually be used for.

basically what we are describing sounds like what Brilliant Database does.
but brilliant has some really cool form designers, web export, and all sorts of nice extras.

and if you wanted to use it to organize home collections, let's say dvd movies.. i don't think we are going to do better than something like this: http://www.collectorz.com/ which has organizers customized for a particular task, which are inevitably going to be funner to use and more tailored to the task.

it would be a fun project if someone was commissioning me to do a specific custom application that they knew they needed and that didn't exist elsewhere - but i've learned the hard way (and still keep making the mistake anyway), that trying to build a general purpose tool without really thinking through the specific applications, is a good recipe for trouble..  i mean look at the dvd database screen at collectorz: http://www.collector...s/mainthumbnails.gif 
surely a tool like that is better for organizing your dvd movies..

however,
we also have the situation where we have this tool, which is a pretty serious database tool, which could be used for lots of stuff,
currently only usable for notes and clipboard storage, and it seems a waste not to go some extra steps to make it a more flexible tool..
i'm especially attracted to the idea of being able to customize the columns completely, and the idea that the tool might take advantage of special tools, IFF they exist in the database.  If you want to keep track of creationdate, lastviewdate, parent hierarchy, favorites, then it could help you add such fields, if not don't add them.

it definitely seems like it would be a cool tool; and there is nothing major i can see that would make it not doable, i just wonder if it would actually be useful to anyone but a couple people..

importing and exporting to excel, printing, etc. are all easy

the other thing that adding the ability to work with other database would do is let you make a more flexible program that didn't try to combine all items into the same databases.. ie clipboard clips could be in a separate database node than personal notes.  todo lists could be in yet another.  this would let you have custom fields for each database.  and i like the idea that each "database" is essentially just a subdirectory on your disk that can be copied and shared, etc.

i'd have to rewrite most of the group-tree management code to handle such a situation, and of course there would be all the column customization code and code dealing with rendering and smartly displaying columns, and im sure some serious headaches when switching between databases and trying to remember views..  right now you can save a "preset" view of the column configuration through the menu.. well that wont make any sense once there are different databases with different columns, and preset column customization views would have to be stored within each database rather than in a file (i think this is actually what you suggested you would prefer anyway :)).

sounds fun - the real problem is just that its not a small job (frankly its been a HUGE amount of work so far, much more than i anticipated) and i still don't know if there is even an audience for this tool - let alone the super generic one.

kfitting

  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 593
    • View Profile
    • Donate to Member
Re: Programming Question...
« Reply #17 on: August 09, 2005, 09:19 PM »
Hmmmmmm.... So nodes would not contain views (filters) into a database, they would contain databases?  In some ways this is awesome.  Like you said, one program to view all kinds of databases.  I like the idea of that.  But, could nodes have different types?  Right now I can see the desire for three types:

- database node (contains entire database like you suggested)
-filter/view node (could be below a database, or could be high level allowing to filter through multiple databases at once?)
-user defined (ie, drag the records you want into the node)

wow. That's cool.  And highly useful. 

Concerning user vs file nodes.  Basically, the tree structure the program shows the user is based off of two things: the node structure contained in the file and the node structure the user has on his desktop.  This way I could have certain nodes (read filters) for specific work I'm doing, but not affect others who are using the same database.  But, we could also have common filters that everyone would be able to use.  As more databases are managed, this gets slightly more confusing... but still a worthwhile idea to consider.

Concerning the collecter software you mentioned.  I looked at the screenshot... I personally don't like it.  I realize I may be in the minority (see below) but I would prefer a straight table view.  The other problem is that you have apps for DVDs, apps for CDs, apps for books, apps for blah.  One specific database for one specific thing.  I love excel for this type of data storage... but imagine Excel with filtered nodes and the quick filtering system a la CHS.  Yes I realized the virtual nodes in CHS, exactly how opera handles email and I love it!  I think every program should come with them (well, maybe not every program...).

Concerning Brilliant database, one of the reason I'm not intrigued by it is that it has all the forms stuff.  Forms are cool, but then you have to set them up.  This program would be ready to use almost out of the box.  Import your excel spreadsheet, create some new nodes with rules and you're there.

cracksloth had some good posts over on the Keynote forums about data storage and how certain types of data are best stored certain ways.  He argued that a note program doesnt benefit from a database behind it, but there is data that does.  In other words, I think "mini database" fits CHS better than notes program. 

All of that rambling aside, I understand your concern for creating an app that only one person will use.  I wish others would join in here and give some kind of feedback.  But, if you make it generic enough, people will find uses for it that you never imagined (look at Keynote).  If people want a clipboard tool, they have it.  If they want a to do list, they have it.  If they have a collection they want to organize, they have it.  And, if you can implement what you're talking about, they can have it in one program shell!  I could go from searching through my parts list database to looking at what tasks I have going on right now, to looking through the clipboard to find that errant piece of data I copied three days ago.  The power here is phenomenal.  Don't understand all the multiple database stuff?  Ok, use one database at a time. 

Sorry, I am extremely biased about this program.  I would love to see it come about.  BUT that is because it fits MY working style.  You need to decide if the extra work and sweat are worth it.  However, if you code it generic I believe you could have your cake and eat it too.  I defer to you and to the opinions of others.... but this would be awesome!

Kevin

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Programming Question...
« Reply #18 on: August 09, 2005, 09:46 PM »
yeah, i should say it's definitely the write way to talk about these things, to hear what one person themselves thinks they want - so it's definitely more useful to hear what you want personally than to hear what you think everyone would want, so these discussions are useful.

ok i understand what you are saying about user nodes - i'll have to think about that, since currently there is no real way to do that now - the tree arragement with the virtual folders and everything is all in the database and would be shared betwen users.

regarding the nodes i was thinking of it like this
at top level root nodes would be databases,
then each database has its own subtree of nodes that act exactly like the current chs system.

so the tree would look like:

* database 1
-*ALL
--*NEW
--*OLD
--*Favotires
--*Recyle Bin
* database 2
-*ALL
--*NEW
--*OLD
--*Favotires
--*Recyle Bin

database1 and database 2 would be totally independent database files - you couldnt (easily) drag and drop between databases, or create virtual views that combined them, they would be firewalled from each other really.

but within a database node youve got the subtree underneath which can hold different phsysical and virtual groups, you can drag and drop betwen groups, etc.

i could let the user create their own virtual groups local to their hard drive and not associated with the database, but you would still not be able to create a virtual view that combined multiple databases.  thats the price for having the ability to have different columns in different databases.  the idea is, different databases would not mix.  its basically you can only be working in one database at a time - its just a convenience that you are shown the different databases as root nodes in the tree, to make it easier to navigate between them.

one advantage of rewriting the group tree node code is if i do completely rewrite it to provide that option we discussed before of showing records within the left sidebar tree if desired...

still a lot to think about it, but its fun to brainstorm ideas and see if we cant make an app out of this.

kfitting

  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 593
    • View Profile
    • Donate to Member
Re: Programming Question...
« Reply #19 on: August 10, 2005, 05:50 AM »
Yeah, that makes sense.  While it would be cool to be able to filter through all databases I can see where that would be almost impossible.  Really, CHS is almost what we're talking about, all you have to do is take out the clipboard monitoring and add a few tiny features.  Not that this means it's trivial to code, however! 

So right now nodes are kept with the database?  I thought you said multiple files would be needed for different views.  Granted, views and nodes may be two different things, I was just using them as synonyms.  If they are in different files, user/file trees arent too big of a deal.  If they are in the database, they kind of lose most of their usefullness.  THe whole point is so some views stay with the file and whoever opens it sees those views, but if I want a certain view for a task I'm doing, I dont necessary clutter other people's view with my garbage.

I think being able to show records in the tree would be a cool thing... more for clipboard stuff than a generic database.  THough, if you can figure out a way to do it you may as well give the ability everywhere. 

Database-wise I think you have 95% of the functionality already in CHS.  The biggest change is in the tree structure.  The database still needs:
- editable cells
- adding/deleting columns
- method for scripting (possibly the hardest, I dont know)

The Tree structure should have (not needs, the program would still be awesome if only one database could be opened at a time!)
- user/file nodes
- Multiple databases in one tree

GUI wise... I dont know.  The current GUI would get you 90% of the way there I think.  Granted, the pane that shows the clip itself isnt needed, or the modify button.... unless you wanted to allow people to store large amounts of text.  How are the actual clipboard contents contained now?  Are they merely a field in the database presented in a textbox instead of a cell?  If so, the GUI from CHS may not need to be changed at all.  All you would need to add are the things stated above (along with all the other stuff you already have on your plate!!) and make a way to turn clipboard capturing/spellcheck etc on and off.  You can already change the view if you dont need to see the clip pane.  You already want to make it so that different nodes correspond to different column arrangements.  If you add the ability to have the program change views on database change, you would be fine.

Ideas, ideas, ideas.  Hopefully it's possible!

Kevin

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Programming Question...
« Reply #20 on: August 10, 2005, 06:47 AM »
ok the first thing we need to do is make sure we are on the same page w.r.t. terms

chs has a concept of "Preset Views" which can be saved arrangements of window panels (what is docked and where), as well as saving information about what columns are visible and in what order they are displayed, their widths, and what is being sorted on, as well as information about how which nodes in the left hand tree are open vs. closed.

this is what i call a "preset view"

now
inside the database itself is a table for the group tree, and a table for the clip items.
in the group tree (or folder tree), are group nodes.

each clip can belong to one and only one group node.

but a group node can also be "virtual", in which cases it specifies a filter rule to specify what other clips(records) from the entire database to show inside it.

SO,
my virtual nodes are what you sometimes refer to as "views".  if you dont mind lets use virtual nodes for this concept.
right now these virtual nodes are indeed inside the database and would travel with it.
i think thats usually going to be a good thing, although i can see your point that if you had many users working on it, you might want individual users to be able to create their own private virtual nodes to hold results of past searches, etc., that other people working on the database wouldn't need to see.
that could probably be implemented with a little bit of work, if i move to a completely custom handled tree, which i am thinking more and more is the way to go, especially if we want to add support for multiple databases.

let's call things that are in the database and would travel with it and be shared by users of it, DatabaseLocal vs things that are only available to current users machine as UserLocal.

so right now, preset views (defining look of program and sort order of column,etc.) are always UserLocal.
and virtual nodes (which define custom filters on records) are always DatabaseLocal.

it sounds like you might really want both to be both.

one might settle for preset views always being UserLocal, but i think you could make the case that you would want to be able to make virtual nodes and specify exactly what columns are visible and in what order they are sorted, etc.

it all gets a little complicated with so many possible ways to use the program.

How are the actual clipboard contents contained now?  Are they merely a field in the database presented in a textbox instead of a cell?

absolutely, there are also fields for graphic images and richtext for when i add support for that.

as you say, the memo panel is the one panel that is really customized to show the two fields (title and clip text) specifically designed for clipboard and note taking.  this is why things like Brilliant Database has a form designer, so you can customize this kind of panel to show you just the info you want in a nice single-record view form..

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Programming Question...
« Reply #21 on: August 10, 2005, 06:48 AM »
ps. you can already turn of clipboard monitoring/capture.

kfitting

  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 593
    • View Profile
    • Donate to Member
Re: Programming Question...
« Reply #22 on: August 10, 2005, 07:46 AM »
Ok, terminology should be good now.  I agree with what you're saying.  In particular I agree with this comment:

so right now, preset views (defining look of program and sort order of column,etc.) are always UserLocal.
and virtual nodes (which define custom filters on records) are always DatabaseLocal.

it sounds like you might really want both to be both.


Like I said before, the more I think about this, CHS has 90% of what is required, it just needs some tweaking as far as user data entry and tree structure is concerned.  GUI-wise you  have everything required.   All thats needed are a few more bullets in your Yet-To-Do list and CHS will be a database/clipboard tool.  Your initial observation of my idea was correct... I was trying to be picky and stubborn!! 

Kevin

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Programming Question...
« Reply #23 on: August 10, 2005, 05:22 PM »
well, i've decided to make chs a full fledged tool for this kind of stuff, so it's just a matter of time, so keep the requests coming.

actually i have a special idea of something to add that will even take it beyong what we're talking about but i'll discuss that after more progress is made.

however, my plan is still to perfect the clipboard + notes aspects of this tool, and only then move to more general database handling.  so keep an eye on the todo list and keep the suggestions coming.

kfitting

  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 593
    • View Profile
    • Donate to Member
Re: Programming Question...
« Reply #24 on: August 10, 2005, 08:18 PM »
Sounds like a good plan to me.  I look forward to future development!

Kevin