Jump to content
uniGUI Discussion Forums

wprins

uniGUI Subscriber
  • Content Count

    120
  • Joined

  • Last visited

Community Reputation

5 Neutral

About wprins

  • Rank
    Active Member

Profile Information

  • Gender
    Male

Recent Profile Visitors

220 profile views
  1. wprins

    OnShowEvent -> Ajax error

    Thanks, that all seems reasonable. Have you tried other browsers, and does it occur there also? To clear the cache press Ctrl-Shift-Del. (Or click top-right three dots button->"More options"->"Clear browsing data", click on "Advanced tab" and delete everything.) It's perhaps easier to open an incognito window and this has the benefit of leaving all your cookies and things alone, press Ctrl-Shift-N: https://support.google.com/chrome/answer/95464?co=GENIE.Platform%3DAndroid&hl=en Is there anything else that is special about this form? And can you make it break in isolation? That is, if you put that form into a project by itself, does it still break? Do you have to do something else first before it breaks? Have you tried recreating this form in its current state from scratch and does that new form still break in the same way? Again, unless you can work out some way to replicate the issue it's going to be very hard to work out what's going on.
  2. wprins

    OnShowEvent -> Ajax error

    When posting errors please always post: 1) Browser + version 2) Version of UniGUI 3) If possible, a MCVE. Admittedly not always easy or possible. But without some chance of replicating the problem it's virtually impossible to help or fix the issue at hand. Additionally, if you have seemingly spurious errors that persist despite removing seemingly everything that could possibly cause a problem, then repeat your test from a fresh browser context (e.g. "Incognito" window in Chrome, or deleting all cached data and then repeating the test.)
  3. wprins

    Application setup strategy

    In the simplest way then, the update form must be given as parameter a callback routine (say "UpdateCustomers()") from the main form containing the grid, that it will call when it's done. Maybe as constructor parameter. Inside the update form, just prior to closing or after saving it then calls the this routine (locally maybe something like "If Assigned(Callback) then Callback()") which in turn results in UpdateCustomers on the form containing the grid being run. (This is a simplified "direct" implementation of a subject and observer directly handing each other a means of notification without "formalising" it and the pattern supporting multiple observers etc. as is the case in the general way this pattern is usually implemented.)
  4. wprins

    Application setup strategy

    Have a look at the "mdemo" "megademo" application which should give you some ideas. Also ask yourself how you would do this in conventional Delphi VCL. If you can describe/implement what you want in conventional Delphi then you can use essentially the same approach in UniGUI. But to make a further parenthetical comment: Your comment re "need to redisplay the grid again with the modified customer" suggests you simply need to notify or otherwise refresh the grid when the modification has completed. How that happens depends somewhat on on how/when the update completes. In a very general sense, you need some form of the "observer pattern", you need to "notify" the grid (an "observer") that its "subject" (the customer list) has changed, which would then trigger a refresh/repopulate/reopening of the dataset or whatever is required.
  5. wprins

    Rename URL

    I've just left a comment on the other referenced post. HTH.
  6. You probably wouldn't save your unigui dll as "page1.php", but rather you would code your UniGUI app to recognize the old URLs and dynamically redirect/reinterpret them in a usable fashion to return a useful response to the client/browser. You would recognize and respond completely as you like in UniGUI, either at the generic server level inside UniGUIServerModule.HTTPCommand & HTTPDocument event handlers, or at a user (session) level inside TUniGUIMainModule.OnBeforeLogin (where you would deal with required authentication first by probably logging the user in first, and after that then record the fact [set a property or whatever on the main form] that the user has asked for some or other form that corresponds to the URL you're recognizing, which you'll then pick up and process when the application main form starts etc.) HTH.
  7. wprins

    Old man needs help

    If it's for a course then there's no point (nor would it be allowed) to just supply you with the solution. The point with asking about Delphi is that if you're more used to Delphi you should perhaps explore the concepts in the comfort of Delphi first as that might be slightly easier to start with, before working out how the same concepts are realised in Java. Ultimately you're learning 2 things at once: The abstract concepts of socket based networking as well as how this is implemented/realised concretely in a programming language, in this case Java. You've not mentioned what you've tried so far and where you've gotten stuck? It might be worth (also) posting your question on a more general programming forum like StackOverflow. But you'll need to more specific and explain exactly where you're getting stuck ideally with an MCVE if possible. You should probably also read this. Hope that helps.
  8. wprins

    Old man needs help

    Is this homework/done as part of some course? What have you tried so far and where have you become stuck exactly? Have you tried writing the same thing in Delphi and/or UniGui yet? If so how did you get on?
  9. wprins

    leaflet maps - unihtmlframe

    You've forgotten to post links to the "other forum".
  10. wprins

    Layout: advanced tutorial

    Note, I've now created a github repo with the code and the fixes I made. It is available here.
  11. Of course you can use plain procedures or functions, but they key thing you must understand is that UniGUI is of necessity a multi-threaded environment. That means that you need to keep in the back of your mind the question whether there could be concurrency problems when you access any "shared thing" out there. Again, while one can mostly program with a single threaded "typical" mindset (ignoring threading issues) providing you're using things belonging to the "current" session, anything else that is shared must be carefully considered regarding possible concurrency problems. What would happen for example in your procedure above if 2 sessions execute it at exactly the same time? Since all the parameters would be distinct and there's no shared variables anywhere, there's no problem in this case. But if there was (for example) a shared global variable referenced in that procedure, then you'd have to think how multiple threads simultaneously trying to update such a shared resource would behave. You'd likely need a lock or monitor or mutex or something to ensure the threads interoperate correctly on the shared resource.
  12. wprins

    UniGUI support, feedback in general and the future?

    Thanks for sharing. Am I right in assuming these are these Firemonkey applications? And what about the internals? Did you use datasnap or something else for the middle/back end? What about client architecture? Did you use FireDAC components or TClientDatasets or something else entirely? (Back in XE5 days I evaluated Delphi's Android support and suffice it to say it was IMHO dire at the time, basically broken and didn't work well enough for me to risk using in production. It looks though like things have come along very well and that I should revisit this.)
  13. wprins

    UniHTMLFrame and Server Path

    We had a similar requirement. First of all, understand: URLFrame.URL is basically a way for you to get the browser to ask for a specified URL (file) in a totally standard "http/s" way. So you must think in terms of "URL" not "shared folder" in the first instance. Next, UniGUI's "FilesFolderURL" gives you a way to get a URL to refer to files in a known UniGUI FilesFolder location, via an HTTP/S URL therefore recognized by the UniGUI server. So, thats one way to get UniGUI to do the "translation" from server based path/file location to something that UniGUI will recognize an serve to a client browser. Of course it doesn't help you because you're interested in some other shared location accessible by your server. It follows that since UniGUI doesn't know about this location, you must implement something similar to what UniGUI does for its file/folder location. In short, to solve this we implemented a servermodule event handler/method (sorry I don't have the code in front of me otherwise I'd perhaps be a bit more specific) that basically recognizes special URL's requests (by prefix) and which further along the URL contains a file-id (AES256 encrypted filename/path in fact). The server module then of course decrypts the request and manually/directly serves up the requested file providing the requestor is allowed to do so of course. That's the essence of it anyway. Walter
  14. wprins

    MVC pattern in UniGUI vs traditional coding to form

    A big reason to prefer more decoupled approaches such as MVC, MVP, MVVM, MV* is testability. If all your logic is inside event handlers then typically it's quite hard to properly test and not possible to test entirely in isolation. This may not be a show stopping problem but it is a consideration at least. (Also see for example the "Humble Dialog" pattern and "Humble View".)
  15. wprins

    TUniScreenMask

    For what it's worth, the above example didn't work as-is in the latest UniGUI version(s). I've updated it, added a few logging calls and instructions to make it clearer what's happening, as well as changing the flow somewhat (avoiding using a custom event in favour of just triggering the actual button click instead.) The code is available here: https://github.com/ByteJuggler/uni_keycap/tree/master
×