Until now, the PROPATH used had some compiled files folders higher in the hierarchy than source file folders for a simple reason: the tool itself is written in ABL and we don't want it to be recompiled on the fly each time it is run. We found that using an optimized PROPATH only for the duration of the compilation - we put it back to normal after the compilation so that the tool can use the PROPATH it needs increased the compilation speed dramatically in many cases, specially for source code files using many include files note that a source file could include just one.
Note that this trick can also be used in OE Architect to speedup the code analysis time spent by Architect to be able to build its Outline view. You can have some fun confirming this with the following code It doesn't take many loops to have execution times in seconds! A couple of results on my machine btw, both methods are faster using This result is probably because, as documentation states,.
String:sadfgilshdfgljshdfgklsjdhfg Method Method Method Method String:sdgffffajksdghakjghakdfjghaajksdghakjghakdfjghasdjghasdkfasdkjajksdghakjghakdfjghasdjghasdkfasdkjajksdghakjghakdfjghasdjghasdkfasdkjajksdghakjghakdfjghasdjghasdkfasdkjajksdghakjghakdfjghasdjghasdkfasdkjsdjghasdkfasdkjfgasdkgasdgasdfjkghasdkfjghasdfkjghasdfhgasdfh Method Method Method Method When you want to verify that a character value does not contain any character i.
When adding records to a temp-table having at least a unique index, it can be faster to trap the ABL error generated on a collision instead of using a CAN-FIND prior to creating each record. The performance of the three methods is relative to the percentage of collisions. A Form needs Here is this routine to translate a qty to string, it is spanish, right now, but I guess that is easy to translate to other idioms, in fact, I would like to know if you translate this to other languages.
DBA Group Use this group to associate any content which relates to database development and deployment, including performance, configuration, and testing and to ask questions which are not linked to specific content. Distinct color generator Generates a given number of distinct colors for use with GUI for. General Principles There are two types of socket, a server socket and a client socket. Each socket has it's own read-response handler in the form of a persistent procedure.
Messages Every time a complete message is received, the message is published as "MessageIn". The following parameters are passed to MessageIn: Socket: The handle of the socket that received the message Message Type: The type of message user defined Message From: The name of the client that sent the message Message To: The name of the client the message was sent to Message Subject: The subject of the message Message Body: The body of the message By default, the complete message is always in the Message body.
Connecting To connect a client to a server, the Connect method should be used. Licence All the code supplied here is licensed under the BSD license. XREF isn't left clueless scale well with lots of PP singletons Callgraph can follow all calls to the functions and procedures in the PPs I ended up having to use two of my old arch enemies: an include file and a global variable.
Finally, the singletonmanager. Although there are a myriad of ways to implement function libraries and find and reference them in ABL, this method satisfies my goals: All compile units referencing the PP program name can be found with a simple text search.
Actually, Callgraph handles supers and session supers pretty well, so finding the references wasn't such an issue, but the ability to use a simple method name like "validate" in more than one PP name collisions was the real consideration. The include file does not make the program's preprocessed output fat or difficult to read. Since the source sports database is located in the Progress install directory you don't need to specify path.
Now you can access the database directly by simply typing pro mySportsDb. This will start a Progress Editor that's connected to the database. This will be a single user connection so nobody else will be able to access the database at the same time. To access the database. This will display all contents of the "bill" table.
Another example of "Hello World" style programs is FizzBuzz. Download your distribution from Progress. If you want a demo license you need to contact them. Make sure you download a bit and not a bit tar file unless you happen to run a bit machine. The download will be a zip archive.
Unpack it and simply run setup. The installation will be graphical but otherwise exactly like the one described below. Once the installation is complete this directory will contain information about the installation as well as files you can save and used for future automatic repetitions of the same installation. Now you will need to insert license keys, company name etc.
Depending on what you're installing you might need to set up different products during the installation. It may not display this or other websites correctly.
You should upgrade or use an alternative browser. Thread starter bangular Start date May 18, I'm attempting to learn the progress 4gl and have run into some major roadblocks. The biggest being documentation. My employer purchased books from progress software. Database administrator and 4gl essentials.
I have to say, these books are rather lacking compared to other programming books I've read. Does anyone know of any progress tutorials available?
What about books other than ones available from progress software? I think the ones from progress are haphazard. I would like to learn basics like inserting and deleting rows from the database, or conditionals, before I even want to get started on frames. Hell, what happened to the simple hello world example that has become the de facto standard when learning a new programming language? It would be nice to have some docs that started off with simple things like -Starting and Stopping the database -Printing data to the screen -Conditionals -Inserting, updating, deleting rows from database -Creating tables.
There are almost certainly two or three factors involved in things like this persisting in the documentation. One is that a lot of the documentation was written a long time ago when awareness of some best practice standards was not nearly as widely understood as it is today For any given release, there is substantial work required to update and add new documentation to cover new features, so it is not surprising that there isn't a lot of resources available for going back to material that hasn't changed to see if it can be improved.
This is unfortunate in many ways because the code examples in particular often convey approaches which are not best practice, which certainly doesn't help people who are learning the language.
Another factor is that a set of best practice standards is not well established and universally agreed upon. To you and I and a bunch of other people, shared variables are anathema, but there are still a lot of folks out there who think they are perfectly OK And, another factor I think is that PSC seems to be very conscious of the fact that there are a lot of people who are not out at the leading edge, especially if they are sitting on million line bodies of existing code.
They don't want to make people feel like they have to change what they are doing in order to move to the latest release. I don't think this pitch is quite clearly focused, however. To be sure, it should be clear to people that they can move to the latest release and it just works. And, clearly they should be provided with guidance on how to make old code and new code work together, something which I think is a bit weak in the current documentation.
But, there also should be good guidance in best practices with new features and what not to use in old features. My impression of the people doing the development on the OO stuff is that they actually have a pretty clear vision, even a bit religious at times. But, this doesn't seem to be making it out in to the examples.
I can go with that a few releases, but sooner or later the docs need to be gone over, updated, and cleaned up. I personally don't get hung up and worry about "best practice" - there's lots different ways to skin a cat, depending on the variations of what a coder's trying to accomplish, personal quirks, etc. There should be a number of different examples showing different ways to accomplish a given goal, with a description of each one's strengths and shortcomings.
However - something as outdated as shared variables should be termed "obsolete", "legacy" or something to convey that it's an old way of doing thins. Certainly not "traditional. One doesn't want new developers getting the idea that SVs are anything other than carry-overs from much prior versions of the language. And so is using include files in lieu of. They may not be running fully-leading-edge code, but if they're running Users should be encouraged to move to more recent, better ways of doing things rather than perpetuating older, obsolete techniques.
And the best way to do that is to a make it easy for them to do so in the language, and b update the docs to point them in that direction. I'd like to see better guidance in how to easily do things now that used to be rather difficult to accomplish in prior versions. I agree with you that it is an important goal, but I also recognize that it is not an easy one.
If someone on the outside were to go through and make a list of all the bad examples, then it might be manageable to respond to those, but fixing them internally means that someone has to do the scan who would recognize a bad example. I'm always a fan of showing more options and explaining why one would make choices, but the specific example this thread started with is definitely a best practices issue Wouldn't it be interesting to have a new, separate best practices manual?
That might lessen the need to fix all the old stuff. Which I think includes guidance on how to use. Continuing the "Shared" thread - why is the "shared" concept being carried forward with new language elements? So maybe we should be documenting "worst practices" instead of "best practices"? Just joking, but it is something we've considered. The problem is, as long as we do support something, we want to support it consistently. And you think we hear it about continuing old conventions, you should hear what happens when we don't!
Some people report it as a critical bug even if we didn't intend to do it! Of course, that's one of the balancing points of being in the software game. The solution that's been in my head for awhile is to let users indicate what things in the syntax they don't want to support, sort of a reverse reserved keyword kind of thing.
I would submit that at the very least archaic outdated methods should not be discussed as "traditional" but "deprecated" or "when nothing better was available". I think shared anything should go away as a dangerous, outdated technique. I can understand existing "shared" support remaining in the language, but adding support for shared "stuff" in new technology like PDS???
Other methods like "choose" have been deprecated by PSC, but nothing's been suggested to replace it. Being able to use 'deprecated' langauge elements is one thing. But obsolete if not dangerous techniques shouldn't be listed as examples of how to work with the product's current technology when there are better and safer ways to accomplish the same thing. While I am a great fan of consistency I think there is an opportunity as the language evolves to find approprate places to move forward.
We all understand why PSC has chosen to support historical syntax in later versions. That policy has its cost, of course, and I'm not sure that it has entirely fulfilled its purpose, as witness the large number of sites vast majority?
Nevertheless, we understand. But, when moving into new areas, like OO, there is no need to support historical code because there is no historical code. And, there is an opportunity to provide guidance toward good usage. There is no reason to allow for a shared object, especially if you provide guidance for what it is that one does to gain the effect of "shared" without the use of shared.
Not only does that provide the programmer new to this area with guidance in the right usage pattern, but it will help to educate him or her on how he or she might rework older code. Supporting a structure because one knows that it is in wide use doesn't mean that one can't also designate it as deprecated.
PSC has certainly done that with some language elements which were and are in wide use and I see no reason why shared shouldn't be added to that list. That does not make it a virtue to guide people toward usage which we now recognize as undesireable. I know that PSC feels it necessary to "comfort" people who are used to procedural code that it is still a valid paradigm, but that doesn't mean that every verb or modifier needs to be called good.
I think developers would like a more expressive grammar for new code constructs like the OO-environment instead of disabling keywords. The new cls-extension was a great possibility to transparantly link cls-sources to a new compiler I can imagine a file extension that doesn't allow GUI-statements other than tracing.
Myself, I think having the compiler throw non-fatal warnings would be a bad idea. It would cause people with some code bases to avoid upgrading and it would break a lot of automated build processes. The compiler should be silent unless there is something fatal or a good reason to expect that the code will not perform as intended like moving colon position.
We have ProLint for telling us things like the use of deprecated features. Then one gets the warning when one is ready to do something about it.
What would really be clever would be for PSC to invest in ProRefactor so that it provided a set of rewrite rules for deprecated features. The compiler already throws non-fatal warnings. That's nothing new.
0コメント