Dave Crozier wrote: > To All, > OK, the time has come to get into Dabo with avengeance - so here I am. I > guess I'll really bug you all in the near future with the regular stupid > newbie questions etc. regarding Dabo - so for that I apologise in advance. > <BG>
Welcome, Dave! > I have a project here at work which would seem to be ripe for use with Dabo > as a first introduction, even though I have tracked the Dabo project from > day 1 - as Ed and Paul will know. What I have always needed is an opening to > get into the product as well as some spare time, both of which are now > available. > > The application to generate is a Timeclock system which is currently written > in VFP using native VFP 9 tables (no autoinc fields or anything special that > isn't VFP7 compatible in terms of table structures)) and a screenshot of the > front end of the application is on my website: > > www.replacement-software.co.uk/Dabo/timeclock_main_screen.png The user-interface looks simple enough. > 1. Obviously my first question to ask is where isit best to start, but > before I start I'll explain the setup here. Start trying out things. Make a form with a grid on it, that saves its data to a sqlite database. Don't worry about how it looks for now, but get it functioning. You'll need guidance to start down this path, but once you get this part done you'll be well on your way to getting your app implemented. > 2. Development system is Windows XP with Komodo IDE which seems to work > really well with Python as I'm used to it for PHP development even though I > do have a copy of the Wing IDE available - any comments as to the > benefits/drawbacks of each when it comes to Python would be welcome. I like the VFP IDE for VFP work, but I like vim and a couple dozen shell windows for Python work. > 3. I have loaded the full Dabo system with SVN as well as Tortoise and can > run all the demos and application builders no problems. I have also looked > at the Wiki and taken in as much as I can without getting into some code > cutting. Great. So you probably have at least a feel for what is involved in making a Dabo app. > 4. Would it be better to start with the Application Wizard Generated code > and work backwards to what I want or start with a blank page and simply cut > code from scratch using the calls into Dabo? Bear in mind that I've been > used to VFP as an integrated Visual IDE for - well let's say it is probably > far too long! Don't start with the AppWizard expecting to work backwards to get what you want. Go ahead and run the wizard on an existing database and see what you get, and play around with modifying the generated code, but don't get bogged down trying to understand how the datanav framework works. At least not until you've settled on a plan. I've built my app up from AppWizard and it is working great, but AppWizard is really intended for getting a simple table maintenance application built without much pain (a CRUD app). While you can build stuff up around what is generated by the wizard, and nothing stops you from adding forms and controls that aren't subclassed from datanav, you may find yourself fighting against the system. Proceed with caution with the AppWizard. > 5. Has anyone successfully managed to access VFP data (read and write) using > anything other than the PHP ADODB software > > http://phplens.com/lens/adodb/adodb-py-docs.htm > > in addition to the mxODBC software > > http://www.egenix.com/products/python/mxODBC/ > > which is a obviously a commercial package. If so, then how, and what are the > potential problems. Initially I want to use VFP tables even though I am > going to migrate the application to a full client/server setup, which brings > me to my next point regarding MsSQL. I've used Pywin to connect to VFP data using the VFP odbc driver, and that worked well. It is Windows-only, however. Dabo doesn't provide an adapter for odbc or vfp at this point, so you'd have to do it in pure python. > 6. In the Application wizard I have tried to use the MsSQL connection in > order to connect to MsSQLExpress (latest version) but had no joy. What is > the status of this feature and plans to implement - if not present already, > or am I doing something completely wrong here? I've never tried it, but MSSQL should work assuming you have the requisite python adapter installed. > 7. I have read John F's recent post/intro to creating a Dabo Demo using Biz > Obj's which was quite useful and hopefully by starting on this project I can > supplement the "beginners guide" with my experiences for the benefit of all > concerned. Excellent. > 8. Most of Python I am happy with so not many problems with the language > here even though I still find it difficult to get into the Python mentality > when "string slicing" where I always have to take a second look before I > plumb in the parameters, but it will come to be second nature I'm sure. The biggest hurdle is probably thinking in zero-based rather than one-based terms. > 9. Finally, my initial attempt is to generate the Dabo equivalent of the > Timeclock application simply as a client, allowing the entry of an employee > number from the keyboard (connected to a card reader) and populating the > grid (see screen shot) with the date/time that the employee clocks in or out > as well as colouring the grid entry red if clocked out and green if clocked > in. The textbox controlling the employee number will be bound to a datasource, which will probably be a dBizobj subclass. It will make the proper entry in the underlying database. The form will refresh, and the grid will reflect the new data. The coloring can be set using grid.dColumn.DynamicForeColor=myCustomFunction that returns red or green depending on what the bizobj reports as the status of the entry. > In addition, the employee picture is shown on the screen (before anyone > else says it, the ugly one in the screen shot is me <BG>). The second phase Displaying images is no problem. Images bound to a database is no problem. > is then to produce the reports and the final phase to convert the VFP > employee admin program into Dabo - but first things first and slowly but > surely I guess. Reports will be a logical conversion from VFP. Probably no biggie. Perhaps the employee admin section of this project would be simple enough to trust AppWizard with... > Sorry about the protracted post and that's it folks. Any comments would be > extremely welcome - good or bad! Again, welcome! Keep questions coming. Paul -- http://paulmcnett.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/dabo-users/[EMAIL PROTECTED]
