Kexi forms & scripting
Page 1 of 1 (4 posts)
Tags:
None
Moderator 
|
Below a post from by Dave Macmurchie originally published in the bugzilla. I proposed to move the discussion here.
|
|
Moderator
|
Dave,
Regarding the bug, crashes are never user's fault, our policy is zero crashes  I tested your database and it doesn't crash here with Kexi 2.7+. There have been a couple of "global" fixes related to memory corruption. This kind of errors could fit to what you observe, especially if that's hard to reproduce. The fixes were backported as usual but not as far back as to 2.3. I recommend newer version of Ubuntu with at Kexi 2.7 or 2.6; newer is better as usual. Basically, Kexi project cannot control how distributions backport kexi to previous editions of their OSes, that's a problem we have to deal with at the moment. Regarding more general questions, for now there's no support for MSA-style event handling methods. Sure, these are often useful and would finally appear, but the idea is also to minimize the need for going down to the imperative code level, but instead offering rich action/macro system as a primary option. That's from my experience as MSA developer back in 90's. I see you have put a "Next" button in your form. If you want to know how to program it so it moves to the next record, here it is: you right-click on it, select Assign Action, and select Next Record action. Unfortunately this particular Go To Next Record action is not yet exposed  Feedback from MSA users is of top priority, so great to hear something that does not happen every week. What would you see Kexi project can do to improve visibility? I know constantly maintained Windows version would do, unfortunately this would need some sponsorship at least initially. For example, while having close contact to actual MSA users, scripting could be more carefully designed. From the beginning, scripting is marked as experimental because it's safer - I am aware how important is the backward compatibility for application development environments. Would you have opinion about choice of languages? Thanks! PS: Kexi Forum topics related to scripting can be found using this query: http://forum.kde.org/search.php?keywords=script&terms=any&author=&tags=&sv=0&fid[]=220&fid[]=221&sc=1&sf=all&sr=posts&sk=t&sd=d&st=0&ch=300&t=0&submit=Search |
Registered Member
|
The statement:
"Regarding more general questions, for now there's no support for MSA-style event handling methods. Sure, these are often useful and would finally appear, but the idea is also to minimize the need for going down to the imperative code level, but instead offering rich action/macro system as a primary option. That's from my experience as MSA developer back in 90's" is the same mistake Microsoft made early on (or they really started with macros and realized the need for VBA) and they are doing it again by trying to get people to use macros. However, this time it's because VBA doesn't port to the SharePoint site so you have to use macros. The truth of the matter is that macros suck because they are way too limited in what they can do. A friend of mine says "VBA fixes everything", and he's right. Scripting allows you to do things that simply cannot be done with macros because macros have to be built for the general cases, like opening a form or report. Some things that scripting allows, or should allow are: 1) The in-process creation and destruction of database and application objects. 2) Performing complicated decission making, such as setting the list portion of a combo box control based on record data or form data. 3) Related to #2, setting captions in forms and reports based on the selected scenario; allowing one to reuse forms and reports for multiple tasks. 4) Automating other applications. With VBA, one can automate Excel, Word, Outlook and other non-microsoft products that present an object model to the developer. 5) Walking users through long, complicated processes, like exporting data sets to a file. The problem with macros, at least in MS Access are the limitations, such as poor error handling, poor security and the limits to what a macro can do. If Kexi is going to be the MS Access for Linux, it really needs to become a development enviroment that includes scripting and a fully functional IDE. I started developing applications in MS Access in 1997 and have made a business out of it. Once I learned VBA, I also learned how bad macros really are and I almost never use macros in projects. Please seriously consider adding scripting to Kexi in the next release. I don't believe you should tout Kexi as the MS Access for Linux unless it has a scripting development environment. On the other hand, if it does include scripting, I believe it could become the defacto replacement for MS Access. Patrick |
|
Moderator
|
Hi pheadley,
Thanks for this feedback, I agree here. SImilarly, I remember myself in 1992 or so using macros and quickly dropping their use completely because scripts (modules) were the way to go. That said, macros and scripting have their own user bases. Sure, if we have to choose, scripting has larger user base and thus we would benefit more from scripts. Advantages of macros are that they are 100% structured; imperative code is by definition based on states and implicit side effects, and has complex means for the control flow, soemthing we professionals use a lot. On the other hand, an idea for macros could be to make them more declarative in nature and richer than in MSA. Looking at QML is somewhat in place: http://en.wikipedia.org/wiki/QML, but I do not mean the notation. Scripting in MSA is poorly structured compared to "professional" programming languages, runtimes, environments. If we look closer, things are not black/white, macros can reuse object model exposed to scripting and many internal structures. So both words share a lot. Regarding SDK features, code completion, and other whistles, I can only assure you tools that Kexi use (Qt and KDE libraries) offer many tools to reuse. For what is already working you can look at Qt Creator and KDevelop and the Kate editor. One action point, once something appears in this document (http://community.kde.org/Kexi/Plugins/S ... ject_Model) you'd be asked for opinions. Well, this way we form one Team as we're developing tools we'd use in increasingly more projects every day! A very important thing for me is relationship with the userbase of MSA power users, that you represent. Let's be in touch
|
Page 1 of 1 (4 posts)
Bookmarks
Who is online
Registered users: Bing [Bot], gfielding, Google [Bot], markhm, sethaaaa, Sogou [Bot], Yahoo [Bot]
