Jump to content

vbdavie

uniGUI Subscriber
  • Posts

    178
  • Joined

  • Last visited

  • Days Won

    6

Everything posted by vbdavie

  1. I understand your point, if it relates to using system resources to keep stateful data. It's true that keeping forms in memory will consume for ram per user. My app will only need to handle from 100 to 500 users. Our system has 48GB of RAM and the ram utilization would be able to handle many more times my requiement. So, I'm more interested in getting app finished faster and easier, and keeping user settings in form data is simpler than saving/retrieving from a database. So, in my situation, I want to keep the settings screen hanging around in memory. My test app showed a login screen, but my usage is really for settings and such. It's like GDI resources, keep them low and use them for the shortest amount of time. Makes sense. Or, it's like the "NO GOTO" rule. I agree from a visual statndpoint, it's a good rule and keeps you out of spahgetti code. But from a MASM/TASM/ASM point of view a lot of constructs like "Case", "If Then", "Break", :Continue", 'Exit" all have implied "goto" built in, and in my 500,000 line app, I have about 12 actual GOTO statements. Thanks for taking the time to make it work. Davie
  2. I agree. BUT, if you run the test program in the IDE and click to "Open Form", and then click the "Login" button, it will have a modal result of "1". NOTE: Make sure to place a break-point inside the callback event where it does the showmessage of the value of the modal result. And make sure you are running in debug configuration and not the release configuration. THEN, click the "Close App" button and then after about a couple seconds, you will see the IDE stop in the callback event, AND if you check the value of modalresult in the callback event, it will be "1". The same value as before when the callback was called the first time. Tell me if you get those results, because I do on my end. And for fun, when you click the login button on the login form, it should enter debug mode at the breakpoint that you set. WHILE the IDE is sitting there in a paused execution, go back to the web page and click on the "X" on the login form. Click it many many times. Of course the server side execution is still halted in the IDE. Now go back to the IDE and tell it to continue, it will then STOP again on the callback, in fact you can tell it to run (F9) several times. It will enter the callback function about as many times as you had clicked on the "X". SO, even though I have the form using "Mask", somehow these events are still comming through. Interesting. Davie
  3. If you are referring to the CallBack function pointing to my main form, then Yeah, normally I don't do that, but there were two options that I could see. 1) I could have the callback inside the login form and refer to controls that were on the main form, OR 2) I could have the callback on the main form and refer to controls on the main form. Since, I have had issues in the past when referring to controls on ANOTHER form, I decided to take the policy of having the callback on the main form. Also, if I decided to have a 3rd orm also show the login form, I would have the callback in that 3rd form. I guess it was just a preference to pick between the two non-perfect choices. See, if I had the code in the login form, then I might have to have a BUNCH of different callbacks sitting in there, if I wanted to be able to use the login form from many other forms. ALSO, if I decided to utilize some other better login form, I could keep most of my code INTACT, while only replacing the call to the NEW login form. So, for maintenence, it was sitting in the back of my mind. Much appreciated that you took a look at it and are taking steps to solve the issue. You are the man!!!!! Davie
  4. Yes, the "Form.FreeOnClose" is set to FALSE. I always check ModalResult, however, it still WILL cause problems, because the InternalClose calls the ExecuteCallBack function which in turn calls my original CallBack function. This function POINTS into my Main.dfm form. And at the time this call is made, the Main form is already destroying itself, so it blows up. Even if it didn't blow up, checking ModalResult won't work, because my callback function will NOT know (based on the ModalResult) that the main form is already gone<freed>. Besides, the ModalResult returns the SAME modal result as it had when you closed the form. IE: mrOk, mrNone, mrCancel, mrWhatEver. It's not like you get some sort of invalid modal result. Make sense? I have attached a "tiny" test project for you. Davie P.S. Do you find it annoying that in web apps, that you can click on a button several times and the server side logic gets called many times? IE: Client:Click, Client:Click, Client:Click, Server:Event, Server:Event, Server:Event.... INSTEAD OF.... Client:Click, Server:Event, Client:Click, Server:Event, Client:Click, ServerEvent. Too bad they can't be synchronized. CloseCallsCallBack.zip
  5. Farshad; In reference to what I posted about the CLOSE method. I moved this to a new topic to please this forum. Basically, I have a testform... 1. I show it 2. I close it 3. It calls my CallBack - as expected Now it's hidden. Now if I close my MainModule OR Close or Free the TestForm, the system calls my CallBack function again. Okay, so I looked at the close method in the TuniBaseJSForm unit, it calls the InternalClose method. It should be near the end of the source code. It makes a few "IF" statements and then calls "ExecuteCallBack". This method of course ends up calling my Test form's callback, but the Test form has long since closed. It's closed because I either clicked the "Login" button or the "X" button in the upper right to close the window. Somehow it's not taking into consideration that the callback had already been called, or testing that the window is NOT showing<hidden>. It does the same thing whether I use Show or ShowModal. Also, if I do a uniLoginForm.Free, it does the same thing. The "Free" method causes it to call the ExecuteCallBack procedure as well. I can't help but feel that "I" am the one at fault in not understanding how these web forms are supposed to work. A real simple test is to put a TestForm.Close or TestForm.Free statement inside of the callback for when the form closes It should produce an endless loop. Davie
  6. vbdavie

    Chart is slow

    Okay, I will. BTW, is it proper for forms to call their callback functions when you issue the CLOSE method on the form? Don't laugh. Here's what I noticed. I do a ShowModal on a form <login screen>. Then on the callback, I make certain things visible. Everything is fine at this point. Keep in mind that the login screen is now gone AND that the callback has already been called. So, everything is exactly as expected. NOW, I have a button that says "Close". I click it and close the main form to essentially shut down the web page. Just like your demo program does with it's Exit1 function. procedure TMainForm.Exit1Click(Sender: TObject); begin Close; end; So, during the closing and destroying of the main form, it looks like <from the call stack> that the instantiated forms are also destroyed. So, the Login form gets destroyed, but during the destroying of the form, IT CALLS THE CALLBACK function. WOW. So, now the system blows up because the code for the callback has already been destroyed by destroying the main form. Why would the callback function get called when the login form has already become invisible? Something doesn't seem right. Davie
  7. vbdavie

    Chart is slow

    So, basically I'm in a situation where I can't tell if the system will meet the company's needs. Trust me on this, whenever I talk with other Delphi developers on the phone or in person or via Email, I HIGHLY tout this software and boast the benfits of it over Radius, Intra-web, HTML-5 builder etc... But what is "difficult", is to explain to the guy, at this small company, that we should spend hundreds and hundreds of dollars for a product that I don't know will work. And worse yet, for a Web-Site that they don't need. They want it but don't need it. The money man likes "mature" products that has been battle tested. I told him that this system is way bitch'n and cool and bad-ass, and that I'm working on deciding if it can do what we want. And if it can, the registration money will fly in your direction so fast it'll make your head spin. But it's hard to convince someone to pay a bunch of money for something to test out. Imagine having to buy a car before you could test drive it in actual sitiuations to see if it really performs the way you want. It's an up-hill battle. And "if" they ask for documentation to see the capabilities, I'll have to hang my head in shame. I'm all in, as far as wanting to use this, it's a matter of convincing others to buy a non-finished product. I feel that I can stumble around with no docs and get basically what I need<generally>. But on some specifics, like the chart building, these are mission critical things that can be deal breakers. I will look like a fool if I tell them to fork over the money and then I find out the system can't do what we intended If it were "me" personally and I had a spare cash laying around, I would just get it. But money is tight. In order for me to not look foolish, can you please tell me the exact amount of the registration fee. I remember reading past posts about differeent prices and something about Sept. But I have no idea what the exact cost is. In fact, ANYBODY comming to your web site will have a hard time finding that cost. I'm not saying these things to hurt or criticise you, I say them so that you understand the position I am in. Quite frankly, if this whole system is maintained by just you and a couple other dudes, I would say WHOLEY MOLEY, these guys are freakishly amazing and talented and doing the work of 20 guys. I've been in that situation before when it was just me, and I was selling over a million dollars of software in a year and advertising in PC-Mag<i got pcMag editor's choice award>, and PC-World<that dates me> and I had one secretary and one guy for shipping. That was it. And so, items that didn't bring in money didn't get the attention they needed. Davie
  8. vbdavie

    Chart is slow

    So, what should I be using in order to "possibly" correct the chart drawing wierdness? Davie
  9. vbdavie

    Chart is slow

    Farshad; Thanks Now where can I get build 1200? Davie
  10. vbdavie

    Chart is slow

    Zig; You said " so my browser stops on "Loading" page. That's why I asked you what is your uniGUI version, but you didn't answer". I have version "Library Version: 0.99.50.1189". When you say your browser STOPS, are you saying you never see my form? I'm confused because your earlier post suggested that you were able to test the web form. I am curious if you followed the instructions on my Tmemo(s) 2. Did you follow the TWO TMemo instructions on the right side of the form? Thanks Davie P.S. Can you give me YOUR EXE version of my test project?
  11. vbdavie

    Chart is slow

    Farshad; The hidden frame is not drawn onto in a programatic way. I have a form on the screen and the lower part contains a "hidden" frame. My program logic does not draw anything inside of it. I then click a checkbox on the form to SHOW the frame and the frame shows up<good>. THEN after I load my data points, the frame that USED to be hidden now shows the graph in a wierd way. Now, I suppose it's possible that when the whole form is being displayed that INTERNALLY there may be some drawing on the hidden frame<i have no idea>. But my personal logic does not do any drawing on the frame while it's hidden. Davie
  12. vbdavie

    Chart is slow

    Farshad, that build# do I need then? ZIG, thanks for taking time to look at it. 1. Did you run MINE or did you RE-compile your own? 2. Did you follow the TWO TMemo instructions on the right side of the form? If you ran MINE and tested with chrome and FF and followed my two tmemo instructions and had no odd effects, please give me your version numbers for those two browsers that you used to test. As for the speed, mine is about 1 full second, not real bad I suppose. I can live with that. It's mostly now the odd chart behaviour. ZIG, sorry about project size, I honestly thought it was small. Thanks for looking into this chart issue. Davie
  13. vbdavie

    Chart is slow

    Okay, I have a TINY project that shows all the wierd stuff going on. Plus the form contains a MEMO that shows how to re-create the issues/bugs. That way you don't have to keep refering to this forum. You can just run the program, load up your browser and use.... http://localhost:8077 as your URL and you are off and running. Just follow the instructions in the two memo fields. In case you just want to run in, I have the EXE in there. It is compiled with XE3. The browsers I tested with are Chrome(latest), FireFox(latest), IE version 9. The issues are graphs not building, or line graphs showing odd legends and lines. I attached a ZIP file that contains all the project files plus the pre-compiled EXE from my XE3 compiler. Have a look and I'm sure you should get the same results that I mention in the two memo fields. Thanks Davie ChartTest.zip
  14. vbdavie

    Chart is slow

    Huh, I will do right now. Thanks for the test Davie
  15. vbdavie

    Chart is slow

    The problem has NOTHING to do with data base access. My datapoints are in a memory array. I assign the data points into the chart which goes fairly fast. It's only in the DISPLAY of the chart where it's slow. For example: You can do this yourself. Make a chart with 300 points and have 5 series. So, I guess that's a total of 1500 distinct data points. Anyway, set up the 5 lineSeries each with 300 points. Then when the page displays, you can CLICK on one of the LEGEND items, so that the selected<clicked> lineSeries will become hidden. WAIT a bunch of seconds. Then if you click the same legend item, you will WAIT a bunch more seconds before the hidden lineSeries becomes visible again. I don't believe there is any server-side action going on here. On my particular system, it's about 7 seconds that I have to wait before the graph is rebuilt and responsive. Try it, you will see. Davie
  16. vbdavie

    Chart is slow

    Hey, I noticed that the charting seems SLOW. If I have less than 50 items or so, it seems "reasonable". Not fast, but acceptable. But if I have 300 points, then WOW, it's slow. And if I add several series then it's a magnified slowness. Basically, I have a stock chart with 5 series in it. The differeent series keep track of different kinds of data over the same date range. I keep track of ONE YEAR (365 days) of data. It takes about 6 seconds for the graph to build and unlock the web page. So, if I have built the chart it takes a while to show it completly. OR if the chart is in a TAB, and I switch tabs to a non chart tab, it is fast, THEN I switch BACK to the chart with many points, THEN i have to wait many seconds before I can click on other things. Have you any experience in this? I turned off animate and it didn't make "much" of a difference. Seems like a lot of people would be complaining about this. Davie P.S. I edited out EXTREMELY and SUPER slow... to be more accurate.
  17. Just a suggestion. It would be nice if there was a new form subfolder. You have "General Discusion", "Installation", "Deployment" and several CATEGORIES of topics. Have one called "DIFFERENCES between Web and VCL programming". In that forum topic group, ONLY YOU would be able to "move" content into it. It would simply be a list of topics that you consider valuable to new people comming on board. A list that is "static" and only changable by YOU. Then instead of searching and searching and reading and reading, there could be a ONE-STOP-SHOP way of getting up to speed faster.Then newbies can get up to speed a lot faster AND the members won't have to keep answering the SAME questions over and over Just a thought. Davie
  18. As far as TDatamodule goes, I created it with the uniGUI wizard that asks me if I want it to be "Application Datamodule" or "Free Datamodule". When I pick "Free", it creates a module based on the "TDataModule". And that is defined from Delphi and not uniGUI. That was my point to ZigZig. IE: There is no TuniDataModule class. And from what I understand from you Farshad, is what I suspected, and that is it IS okay to create the datamodule object using DM:=TDataModule1.Create(Nil) as long as I keep it in one of my session specific objects<like mainmodule>. The way I understood Zig was that I couldn't do that and that that wouldn't be threadsafe. But I see in your post that you agree that it WILL be safe as long as I do what I mentioned. Okay, great. Now, for the TfrxRichView object, I decided to put code in my fastreports source to debug it and found this in case anyone is interested... constructor TfrxRichView.Create(AOwner: TComponent); begin inherited; FRichEdit := TrxRichEdit.Create(nil); //based on a VCL component FRichEdit.Parent := frxParentForm; SendMessage(frxParentForm.Handle, WM_CREATEHANDLE, frxInteger(FRichEdit), 0); FRichEdit.AutoURLDetect := False; { make rich transparent } SetWindowLong(FRichEdit.Handle, GWL_EXSTYLE, GetWindowLong(FRichEdit.Handle, GWL_EXSTYLE) or WS_EX_TRANSPARENT); FTempStream := TMemoryStream.Create; FTempStream1 := TMemoryStream.Create; FAllowExpressions := True; FExpressionDelimiters := '[,]'; FGapX := 2; FGapY := 1; FWysiwyg := True; FHasNextDataPart := False; end; Points of interest. The reference to frxParentForm IS A GLOBAL OBJECT Jerks. And to make matters worse, the use the SENDMESSAGE. Now why are these interesting.... The frxParentForm being GLOBAL means that it can NEVER be threadsafe. Okay, bad news if several users at the same time. Now let's PRETEND that you can ENSURE that only ONE user has a session at any point in time, one would think that the frxParentForm would not cause an issue, BUT we have the SENDMESSAGE. Of course if the window handle doesn't have a message pump, then you are screwed and it will wait forever Okay, so all that makes sense correct? Here's what's weird. As I mentioned before, I can loop in my web form's buttonclick event over 1000 times to create the report object. I'm thinking.... if there is NO message pump, then shouldn't it lockup on the very first create? Bizzare how it works for awhile. Hmmmm Interesting. Solution: So, I guess I can't produce my nice reports that have a richview on it, the only other solution I saw here is that someone decided to spawn an EXE program and pass some parameters on the commandline that would create the report and save it to a known specified filename. Then the DLL code<when the spawn is done> would see the file that then send it to the end user. Is that the best solution that you know of so far, given that I would like to use the RichEdit? Thanks Davie P.S. I guess I'm too late to buy the product by Sept 1st. oh well.
  19. Very nice. I understood almost all of what you say. Very clean. The one point I still don't get is this. You say that If I use the " DM:=TDataModule1.Create(Nil) " way of instantiating the object, you made it sound like <to me> that this object would/could be used by ALL THE SESSIONS? That's the part that I absolutely don't get. I thought that if I create an object that it returns a pointer to a block of memory that is allocated for that specific instantiation. And that if I did another DM:=TDataModule1.Create(Nil), that that would allocate A NEW block of memory for for the second instantiation. And thus the pointer returned for the second creation line of logic would in fact be a different value. Thus I would have TWO pointers pointing to TWO different memory locations. If that is in fact the case<i believe it to be fact>, then if in my main module logic I have a line of code that says "DM:=TDataModule1.Create(NIL)" and then store the object pointer into my TuniMainModule's public variables, then it would in fact be safe, since each session would have it's own copy of the TuniMainModule object. And that the DM object pointers that I am storing into the uniMainModule are in fact pointing at TWO DIFFERENT memory blocks. Each one distinct. Which would mean that any reference/reading/writing to the DM in session#1 would NOT interfere/modify/read/access with the DM that is stored in seesion two's uniMainModule. I would bet serious money on that. Buy hey, I've been wrong before, so please spill the beans. Thanks Davie
  20. ZiGZig, First of all, I do NOT want to spend hundreds of dollars on a product with ZERO documentation and conflicting comments from various users when I don't even know it will be able to handle what I need. I've spent money on Fast reports cause it dd what I needed and it had docs and decent support. I paid money for SQLMemTables for the same reason. I paid for BusinessSkinForms for the same reason and on and on. Nowhere have I spent money on a beta product with no docs. Sorry. I would even be WILLING to spend the money, IF i knew it can do what I want EVEN though there is no docs. And that is what I am trying to do. Trying to see if it will do what I want. Second, you mention to use TuniDataModule. I have no freaking idea of how to do that. I have no source I have no ability to SEE what unit contains that TuniDataModle in the first place. IN FACT, when I click "New" in the IDE, and pick the uniGUI for Delphi objects, then I pick the uniGUI Data Module, it auto creates a unit for me WITH TDATAMODULE. So even the UNIGUI system uses the TDATAMODULE object. Way too many inconsistiencies here. Try it yourself. Click on the IDE, "File" then "New" then open up the "Delphi Projects" tree, the click on the "uniGUI for Delphi" item and you will see 6 objects (Application Wizard, DataModule, Form, Frame, Inheritble Items, Mobile Application, Mobile Form). Pick the DataModule and you will see EXACTLY what I am talking about. You said..... About DataModule vs. UniDataModule: even if you are not sharing your DataModule with other threads, what will happen when several concurrent users will access your web application ? Your DataModule is not thread safe ; dbExpress, dbGo and FireDac components are not thread safe. The only way to avoid thread conflicts is by using TUniDataModule, wich implements one DataModule for each concurrent session. Wait a minute. I've been doing object programming for decades now. I must have a huge misunderstanding on how object programming works. I thought that if I created an object in one thread and that if that object is NEVER shared/referenced/used by another thread, that there is NO problem<even if the object is NOT thread safe> If I understand what you typed, it sounds like you are saying that TuniDataModule<which i can't find> will make several DataModule objectS, one for each session<thread>. And that this way is good. BUT yet in your first sentence you said that "Even if you are NOT sharing your datamodule with other threads....." That makes me think that if I create an object and ONLY MY THREAD<session> will make use of it, that there will be problems. Did I understand you correctly? Because that makes no sense to me at all. Huh. TfrxRichView IS NOT a visual component that you can plop onto a form and play with properties. It is part of the FAST REPORTS set of objects that you can plop onto a FastReport form. So, I don't know what you are talking about. It's an internal thing that fastreports creates to make a report do things. Just like the fastreports TfrxShapeView or TfrxMemoView. These are internal to FastReports so that the FastReport Designer can allow you to visually build a report layout. It's this TfrxRichView that I am "claiming" seems to cause a problem.... and wanted comments from people that used FastReports to hear what they had to say about the TfrxRichView thing. Thanks for your fast reply. Davie
  21. Okay, point taken on question3, but what about question 1,2 and 4 ? Keep in mind that UniGUII DOES take over the AddDataModule function to<i think> correct issues. I am working blind since I don't have source code, but that's what I think is going on. I see conflicting Talking points on TDatamodule depending on if the module is to be SHARED amongst threads or not. I am NOT sharing the module with any other threads. Davie
  22. I just spent a day trimming down a large datamodule that had about 20 reports on it and it finally came down to this one report with a TfrxRichView object on it. After I removed it, the datamodule would load. Here's what's weird. I DO NOT share the datamodule object with other threads, so essentially... It is not multithreading the datamodule object<which contains the fast report report-objects>. I can create/destroy the datamodule many many times in a row. I tried a loop of create/destroy with the loop going up to 1000 times. I thought... "GREAT", but which I click on the button on the form to perform my action again, it locks up on the very first "create" call. QUESTION: Why is is incompatible What about the TfrxRichView is not compatible if considering that I AM NOT sharing the object with other threads? QUESTION: Strange lock up How do you explain that I can create/destroy/create/destroy 1000 times in a row perfectly, BUT then when I click the button to perform my buttonCick event again, it LOCKS UP on the very first create? pseudo-code MyButtonClickEvent(params) Var DM:TDataModule1; begin for x:=0 to 1000 do begin DM:=TDataModule1.Create(uniApplication); DM.Free; end; end; QUESTION: Best practice for instantiating TDataModule There are many ways to instantiate an object. 1. DM:=TDataModule.Create(Nil) 2. DM:=TDataModule.Create(uniApplication) 3. DM:=TDataModule.Create(Self) 4. Maybe others... Which way is the proper way? I have been in the habit of using (NIL) and then freeing the object myself. QUESTION: TDataModule's AddDataModule overridden I heard issues about the adding a datamodule logic in delphi that is "flawed" for a multithreaded environment. I see that YOU have taken over the "AddDataModule" function to do your own thing. DO you do that in order to prevent delphi flaws? Should I now assume that the adding of a datamodule will be proper<since you "unigui" takes over the adddatamodule logic> ? Thanks Davie
  23. What does background=true do? Does that create additional threads? If it fails on 64bit, does that mean it's not thread safe? Hmmm. EddyRocha sent me this.... frxReport.EngineOptions.EnableThreadSafe := True; What does that mean? Does that mean it's not threadsafe to start with and you have to set a property? Davie
  24. GEEEEEEZ, I figured it out. See, the main form on the demo has a "Frame" control that contains the starting photo. I put all my controls on that frame and as I added controls to the "UMain.pas" , they woiuld appear on the MAIN form. No big deal, that's the way I expected the inheritence to work. BUT if I "changed" a control on the Umain <like the autopost> then those changes would NOT appear in the MAIN module. So, basically, I made the correct change, BUT it wasn't reflected on the MAIN screen I wasted a bunch of time discovering that. I noticed that as I moved a bunch of columns around in the dbgrid, the columns did NOT appear moved when I ran the program. I then looked at the "main" form and much to my amazment, the dbgrid was NOT updated. So, then I clicked the "Revert to Inheriited" menu item wihen I right clicked on the frame control on the MAIN form. That refreshed the MAIN form to use the CURRENT contents of the UMain frame So, niow the checkbox works. I wonder if there is a way to make it so that when any changes are made to a frame that ALL the forms that utilize the frame will auto-update. ??? Davie
  25. Fantastic. I set the autopost to TRUE. Let me test..... hold on..... :( Still no go. I went to the Grids/CheckBox demo and clicked on the LAST column that says "Auto Post=True". I think internally in the dataset, it's the last field called "Shift". Anyway, the demo grid works GREAT, but MY grid does NOT. I set the dataset OnAfterPost event to point to some method of mine to tally up the checkmarks. I presume that's the way to change the on-screen counter as the user palys with the checkmarks? Here's my grid definition for the grid that does NOT act correctly. object DBGridAccounts: TUniDBGrid Left = 16 Top = 312 Width = 425 Height = 107 Hint = '' ClicksToEdit = 1 DataSource = DataSource1 Options = [dgEditing, dgTitles, dgIndicator, dgColumnResize, dgColLines, dgRowLines, dgRowSelect, dgConfirmDelete] WebOptions.Paged = False WebOptions.PageSize = 999 WebOptions.FetchAll = True LoadMask.Message = 'Loading data...' OnDblClick = DBGridAccountsDblClick Anchors = [akLeft, akTop, akBottom] TabOrder = 16 OnColumnSort = DBGridAccountsColumnSort Columns = < item FieldName = 'Tag' Title.Caption = 'Tag' Width = 32 Visible = True Expanded = False Sortable = True CheckBoxField.AutoPost = True CheckBoxField.FieldValues = 'true;false' CheckBoxField.DisplayValues = 'Y;N' end item FieldName = 'Value' Title.Caption = 'Value' Width = 64 Visible = True Alignment = taRightJustify ReadOnly = True Expanded = False Sortable = True CheckBoxField.FieldValues = 'true;false' ShowSummary = True end item FieldName = 'Cash' Title.Caption = 'Cash' Width = 64 Visible = True Alignment = taRightJustify ReadOnly = True Expanded = False Sortable = True CheckBoxField.FieldValues = 'true;false' ShowSummary = True end item FieldName = 'Account' Title.Caption = 'Account' Width = 85 Visible = True ReadOnly = True Expanded = False Sortable = True CheckBoxField.FieldValues = 'true;false' ShowSummary = True end item FieldName = 'Company' Title.Caption = 'Company' Width = 125 Visible = True ReadOnly = True Expanded = False Sortable = True CheckBoxField.FieldValues = 'true;false' ShowSummary = True end item FieldName = 'Title' Title.Caption = 'Title' Width = 400 Visible = True ReadOnly = True Expanded = False Sortable = True CheckBoxField.FieldValues = 'true;false' ShowSummary = True end> end You can see that I set the AutoPost property. So, very wierd. There must be an ODD set of properties that ends up showing the odd behaviour. Maybe it's because mine is the first field instead of the last? I don't know, but it's wierd that one grid works fine and the other does NOT. Do you see anything out of the ordinary on mine? Davie
×
×
  • Create New...