Why do you need to open up so much and at the end close it down? Shouldn’t every ui do that as needed?
Doesn’t the data get stale if you pull it at onset? The work I do lately is all processing via a variety of message ques and no ui. You read the message and then identify what if anything you need to do or pass it off to the erp for the work to be done. Guess I live in a workflow hell. I get the attributes from the message and deal with it on its own terms. On Fri, Feb 22, 2019 at 11:05 AM Paul H. Tarver <[email protected]> wrote: > I hijacked the original thread with a reply changing the subject and > adding an [NF] flag to the subject because a small comment Kevin made > caused me chase a different rabbit for a little bit. > > I have reviewed Xojo on a couple of different occasions over the past few > years and I have tried to work my way through the book that was written to > teach people how to program it and I find myself drifting by the 3rd or 4th > chapter every time. Not a fault of the author; just rather a fault of me > wanting something a little more advanced. Anyway, I've run into a couple > of hurdles with trying to learn Xojo and perhaps someone here has some > suggestions to help me out. > > Try not to laugh at what may be very dumb questions! :) > > 1) I build a lot of similar but customized apps using a shared library of > tools I've developed over the past 25 years. Every app I build contains a > LOT of forms, reports and programs shared by all my applications as well as > a lot of forms, reports and programs which are copied from previous > projects and then customized for the current client. While I have seen > multiple Xojo advocates confirm a similar process is possible, but I cannot > find clear explanations of how to make that happen. > > 2) Every Foxpro application I build starts with a .PRG which reads a > configuration .INI file and then setups up the environment, displays a > splash screen, checks my version numbers, calls a database update process > if a version change is detected and if all is good, it displays the main > screen for the user. Once the user chooses to exit my application, a > shutdown process is initiated and everything is closed in an orderly way. > That having been said, I have been unable to find source code to a simple, > complete Xojo application or instruction book that can walk me through the > start to finish logic and firing order of all the start-up and shut-down > events and allow me to compare that to the process I'm so familiar with in > Foxpro. > > 3) Are there any good white-papers or books by Foxpro programmers that can > provide insights into translating my Foxpro knowledge and skill directly > into Xojo. > > I use Foxpro on a daily basis for my business because I cannot find a > language that satisfies my clients' needs the way Foxpro does. I would love > to be able to say I have a backup language like Xojo, but I get only so far > before I give up and go back to what I know and love. So let's assume Kevin > is correct when he states Xojo is " a viable language for VFP developers" > because I do not want to go down the rabbit hole of considering all the > other alternatives for this sake of this discussion and share with me any > tips that can help me understand Xojo on a higher level beyond just > creating a simple form. I want to understand Xojo at a Complete Deliverable > Application level and talk about mimicking the features I depend upon in > Foxpro to share a library of tools, forms and code across hundreds of > similar custom applications. > > Paul H. Tarver > > > > -----Original Message----- > From: ProfoxTech [mailto:[email protected]] On Behalf Of Kevin > J Cully > Sent: Friday, February 22, 2019 8:11 AM > To: [email protected] > Subject: RE: false news.... > > Well, a lot of that article is correct, even though I don't want it to > be. VFP as a *language* is as secure as the programmer programmed it to > be. VFP as a *database* isn't secure itself. You can encrypt fields. You > can encrypt the directory that the data is stored in. But DBF data isn't > secure. You wouldn't store social security numbers or credit card numbers > in Excel spreadsheets, right? > > I've haven't recommended DBFs for storage for over a decade now. There > are better storage mechanisms such as Postgres, MariaDB, and even SQLite > which can be set up as an encrypted database. VFP as a language is still > valid, although it will never be able to create 64bit applications but that > is a different subject. [Insert Xojo plug here as a viable language for > VFP developers.] I had a potential client where they based their primary > keys based on employee Social Security Numbers. They didn't like it when I > told them that they'd need a complete rewrite. Notice this would have been > the case no matter what language/technology they were using. It was just > piss poor design. > > It appears from the article, that when the vendor was notified of the > situation, that they were able to quickly address it although the article > didn't say what that solution was. Probably encrypted the field? Hash the > field with an external secured table containing the sensitive data? Who > knows. To me, that's a win. Hopefully the vendor contacts all customers > notifying them that there is a vulnerability and that there is a solution > available. > > As Ted Roche always says "Security is a process". > > -Kevin > > -----Original Message----- > From: ProFox [mailto:[email protected]] On Behalf Of Dave Crozier > Sent: Friday, February 22, 2019 6:07 AM > To: 'ProFox Email List' <[email protected]> > Subject: VFP: false news.... > > Ignorance and stupidity still runs in the so-called “expert consultant” > fraternity. > > “An outdated software that is used by about 200 Vermont municipalities and > the Vermont Tax Department has long contained flaws that exposed sensitive > information including Social Security numbers, according to an IT > consultant and the software company’s founder.” > “You could make a strong case that Visual FoxPro shouldn’t be used on a > government level,” Johnson said. > > > https://vtdigger.org/2019/02/05/consultant-outdated-software-left-worker-information-exposed-200-towns/ > > Thankfully the software owners realise that it isn’t a fault in VFP, it is > a fault in the designing of the infrastructure. > > Expert: > Ex - Out of date > Spurt – a drip under pressure!! > > Dave Crozier > Software Development Manager > Flexipol Packaging Ltd. > > ﴾⚆ᨎ⚆﴿ > > > > Flexipol® Packaging Ltd > T 01706 222 792 > E [email protected] > W https://www.flexipol.co.uk/ > Follow us: > Unit 14 Bentwood Road > <https://maps.google.com/?q=Unit+14+Bentwood+Road&entry=gmail&source=g>, > Carrs Industrial Estate, Haslingden, Lancashire, BB4 5HH > > This communication and the information it contains is intended for the > person or organisation to whom it is addressed. Its contents are > confidential and may be protected in law. If you have received this e-mail > in error you must not copy, distribute or take any action in reliance on > it. Unauthorised use, copying or disclosure of any of it may be unlawful. > If you have received this message in error, please notify us immediately by > telephone or email. > > Flexipol Packaging Ltd. has taken every reasonable precaution to minimise > the risk of virus transmission through email and therefore any files sent > via e-mail will have been checked for known viruses. However, you are > advised to run your own virus check before opening any attachments received > as Flexipol Packaging Ltd will not in any event accept any liability > whatsoever once an e-mail and/or any attachment is received. > > It is the responsibility of the recipient to ensure that they have > adequate virus protection. > > > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Terms & Conditions: > Notwithstanding delivery and the passing of risk in the goods, the > property in the goods shall not pass to the buyer until the seller Flexipol > Packaging Ltd. ("The Company") has received in cash or cleared funds > payment in full of the price of the goods and all other goods agreed to be > sold by the seller to the buyer for which payment is then due. Until such > time as the property in the goods passes to the buyer, the buyer shall hold > the goods as the seller's fiduciary agent and bailee and keep the goods > separate from those of the buyer and third parties and properly stored > protected and insured and identified as the seller's property but shall be > entitled to resell or use the goods in the ordinary course of its business. > Until such time as the property in the goods passes to the buyer the seller > shall be entitled at any time > > > --- StripMime Report -- processed MIME parts --- multipart/related > multipart/alternative > text/plain (text body -- kept) > text/html > image/jpeg > image/jpeg > image/png > image/png > image/png > image/png > --- > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/CAJidMYKv09Uwo-970+F=Ssd+m=ay9d0og_jgwcshhmumsje...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
