Ben: Before the fix my jpeg variable was defined as: vlogo = ['map_1.jpg'] and the variable type was set to VARBIT This approach was taken from one of the articles at the RBTI web site when I started using photos in forms.
This is the error code that I received from the OS ========================================= This program has performed an illegal operation and will be shut down If the problem persists, contact the program vendor ========================================= Here is the response I got from RBTI: ============================================== After spending several hours to isolate the issue in your example, I have concluded that it is the main form image (map_1.jpg) that is causing the problem. It may be caused by either the image type or size, I don't know. To fix the problem, change the definition of the vlogo variable in the W_RAMS_MAIN form to look like the following: vlogo = 'map_1.jpg, dmstretch' Also, make the data-type TEXT. Then, right click on the object, and click Properties. Check the box for Custom, and select BlobDraw from the drop-down list. This will now process the image through the RBlob.DLL which seems to correct the problem. ============================================== The solution above seems to have solved the problem (in my case). Please note that the variable definition approach I had originally is valid and displayed the jpeg fine...well ...except for the crashing down the code... As far as the length of the command line, I know that there is (at least use to be) a physical limit for the length of the line (72 characters?), I know that there is also a limit on the total length of the command line regardless of continuation characters; one time, when I was building a very long command line, I did get an error message indicating that the command line was too long (512 characters?) I understand this is particularly touchy when using RCode to compile your applications. Maybe Razzak can chime in and shed some light on these limits, as they may have changed in the later releases. Also, I remember that in the old WIN95 machines, I disabled disk caching as it was creating problems when using the R:Base 45.++ for DOS; I am not sure about the details, but I seem to recall that there were some settings in R:Base that needed to be tweaked. Again, I believe that with al the brainpower in the List, sooner or later we will find a way to solve this problem. Javier, Javier Valencia, PE President Valencia Technology Group, L.L.C. 14315 S. Twilight Ln., Suite #14 Olathe, KS 66062-4571 (913)829-0888 (913)649-2904 FAX -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ben Petersen Sent: Friday, January 03, 2003 5:48 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Criteria For MyUnstablenessWithR:Base6.5++Build 1.862 Javier, I use BMPs on the opening screen of the app I mentioned. I think I focused too much on JPEG when you posted this before. I've learned that you should not clear and re-initialize varbits...but there's more?<g> Can you describe what you've done? If you think about it, this has the same flavor as Alastair's discovery regarding illegal background colors... (although I wasn't fortunate enough to have used them <g>) there is not an immediate effect, but later, in his case I think it was form use?? How did your's present itself when did the problem show up? When you mentioned short code lines, do you mean in total length or the liberal use of the continuation character? I want to be clear here that it's not my intent to find fault with RBase. It's direct, elegant and powerful. I don't mind work-a-rounds, for the most part. I don't mind changing my coding style. And I have written volumes of "crappy" code that I've had to deal with. I also like to know what I must work a round, and how my coding style needs to change... so I find these threads very valuable. Ben Petersen On 3 Jan 2003, at 12:18, Javier Valencia wrote: > Ben: > I recently had a problem that kept crashing the system, I checked, > traced and verified every way that I could think of without luck. I > finally sent a copy of the data base and application code to RBTI and > they figure out that the problem was caused by a jpeg file (blob) > displayed on the opening screen that was causing the problem way down > the code, they suggested a workaround that seems to be working. I > still do not know exactly why it happened but I am sure glad that my > problem was solved, overall I am pleased with the latest release; once > you get the kinks worked out (and herein lies the problem) it works > pretty solidly. I am hopping to switch to 7.0 as soon as feasible. As > a developer, sometime I get extremely frustrated (as my receding > hairline will attest) when I run into problems for which there is no > apparent cause and spend hours and hours trying to find a solution > and/or workaround. My experience is that 9 out of 10 times, it is > indeed a problem with code brought out by stricter enforcement of > syntax by new releases, the rest of the time I have submitted to RBTI > and so far they have been able to help every time (touch wood!!!) > Because of these problems, I have adopted some quick rules on all new > code or when I re-write existing code (in addition to the ones I > posted before): Keep lines short, sometimes long lines will exceed the > limits of the interpreter/compiler and it will be difficult to debug > as the syntax appears correct, but in fact R:Base is not seeing the > entire command line. RStyle will show the limit line, but if I > remember correctly, it will not call it an error. I use the entire > command name (no abbreviations) as it prevents confusion when the > short name for new commands may conflict with an old/existing ones. I > use upper case for all R:Base commands in the code, it helps a great > deal when debugging. RStyle is very good at finding unbalance > parentheses, quotes, commas, etc. Use only one rbase.cfg file as the > settings saved in a different file can create problems; this is the > first thing I check when an application will work in one computer but > not on another, many times I found that a different rbase.cfg in the > path was creating problems. Program defensively, account for all the > keystrokes that users may use, i.e. [ESC]. Do not hesitate to post the > issue to the list, I have found problems I did not know I had until I > saw someone else's post and checked my own code. And finally, the > golden rules of programming: "The user never knows what he wants and > seldom knows what he needs" and my all time favorite: "You cannot have > a foolproof system because fools are too smart" I realize that the > "golden rules" do not directly apply to the issue at hand; however, > sometimes they help keep things in perspective... > > Javier Valencia, PE > President > Valencia Technology Group, L.L.C. > 14315 S. Twilight Ln., Suite #14 > Olathe, KS 66062-4571 > (913)829-0888 > (913)649-2904 FAX > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ben > Petersen Sent: Friday, January 03, 2003 3:46 AM To: RBASE-L Mailing > List Subject: [RBASE-L] - Re: Criteria For > MyUnstablenessWithR:Base6.5++Build 1.862 > > Dr R> > > ttbomk I follow the guidelines you set out below. And my apps run > perfectly on my own machine in testing, sometimes requiring a pause > for unknown reasons; but leave here working none the less. > > And, in general, run fine on the majority of my client's systems. It's > the exceptions that are the show stoppers. On two occasions I have > tracked the problem down to the offending line of code... inserted > blank lines above and below, and the problem was solved. This was > required for two different clients within two different code segments. > > Another mystery required calling Hawaii with pcAnywhere over and > over (crashing the client's system each time and they restarting) > until I came to a block of code that was as simple as pie... could not > be the problem, works on a half dozen other computers, but not theirs. > I've never resolved it and it doesn't occur anywhere else. > > For the record, each was tested on my computer using the same > apx and database files. > > I don't believe that RBase is "at fault"... at least not directly as > in erroneous code. But maybe something external is not accounted > for... anti virus software, a particular driver, the phase of the > moon... > > Allastair's attempt to find commonalities to these boo boos might > prove helpful. > > Ben Petersen > > > > > On 3 Jan 2003, at 3:51, A. Razzak Memon wrote: > > > > > At 08:26 AM 1/3/2003 +0000, Alastair Burr wrote: > > > > >In the mean time does anybody else who is having these crashes have > > >any of the following conditions: > > > > > >Is the form that might be the cause one that is based on a temp > > >table? Do you have any "set" commands that are database linked but > > >with no database connected prior to calling the form? Or maybe ones > > >that need the owner password? Do you have any other commands that > > >return an error that you believe that you can safely ignore prior > > >to calling the form? Disconnect when there is no db connected, for > > >example. > > > > > > > > Well Alastair. > > > > I think, you are answering your own questions. And, let me see if I > > can help you understand: > > > > 01. If the form is based on a TEMPORARY TABLE, you, as a > > programmer, > > need to make sure that the related TEMPORARY table exist > > before using the form. > > > > TEMPORARY TABLES are disappeared when the database is > > DISConnected. > > > > You will need to create startup file to re-define those > > temporary > > tables. > > > > 02. Use CVAL('Database')) option to return a text string > > containing the current connected database or NULL if > > the user is not connected to a database. This can be > > used to ensure that the user is connected before > > trying to execute some code. The example below shows > > how this might work. > > > > SET VAR vDB = (CVAL('Database')) > > IF vDB IS NULL THEN > > CONN MyDB > > ENDIF > > > > SET VAR vDB = (CVAL('Database')) > > IF vDB IS NULL THEN > > PAUSE 2 USING 'MyDB is currently unavailable' > > ENDIF > > > > The check is repeated to ensure that the attempt to > > connect to the database was successful before > > continuing with the command file. > > > > 03. Make sure to pre-define all global variables used in forms > > with > > appropriate data type. > > > > 04. Use ENTER USING FormName or EDIT USING FormName at > > the R> prompt to make sure they work. > > > > 05. Make sure to SET MESSAGES ON and SET ERROR MESSAGES ON > > while testing and debugging your forms, reports, command > > files, etc. > > > > 06. Use TRACE to narrow down the problem, if any, in your code. > > > > 07. If you are using any bit map buttons on form, make sure to > > use BMP. > > (works better in 6.5++ for Windows) > > > > Of course, 7.0 supports ALL kinds of buttons and graphics, > > including maps and GPS coordinates. > > > > Hope that helps! > > > > Very Best Regards, > > > > Razzak. > > >
