Jump to content

Dany Marmur

Members
  • Content Count

    143
  • Joined

  • Last visited

  • Days Won

    3

Dany Marmur last won the day on May 26

Dany Marmur had the most liked content!

Community Reputation

51 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Dany Marmur

    Delphi for HUAWEI OS?

    When i worked with embedded for industry, the company had it pinned down, what countries the product could not be exported to, because of this or that chip or functionality. Also, when you subscribe to any advanced library (like StreamSec) you have to sign not to develop in Iran and other countries. This is nothing new. But for a president to affect millions of end-user devices out of political "signalling politics", this can only end in woes and disasters. This is historical, actually. And quite serious. The next step is that all the security-assist-IT functionality in your modern Volvo car just stops working when you cross from Calais to Dover. The list will go on and on. Really stupid politics.
  2. Dany Marmur

    Delphi for HUAWEI OS?

    We need to wait for Brexit before implementing China(r).
  3. OK, i'll try to expand, but these things are opinions, no "hard facts", sorry. When i studied educational theory at uni there was this professor that had an explanation of why 10 or 16 point lists was no good. We all learn differently and i do not know where you are. But for me; implement it!! Do not think too much. For example, your search logic in a DM and your 19 forms. Then you will notice small pesky things that works in one dialog but not the other. You will refactor, consolidate and maybe you will be more happy with the 2nd, 3rd of even 4th refactoring. You have other projects perhaps. I cannot give a series of steps. There are patterns out there, of course. Also managing dialogs/forms usually is not an area where you need to be vary of performance. You'll notice when you forms/dialogs get so complex they start to take annoying time to open. It's the search logic that should be optimized. So your OT problem is a rather good example for experimenting. There are so many ways to do any given thing and only the bad solutions are bad. Simply create (if you have the time and budget). HTH, /D
  4. That is the million dollar question, so to to say! I think you got the gist there from my confused posts.
  5. IMHO something you should do something about. Does not sound 100% "healty/smart". Dynamically or statically (an oxymoron) i think is also something you have to consider. Everything you put into DFMs will be read by the "subsystem" at form creation. It's simply a question of "who's in control". Difficult to express in a third language. At form creation the DFMs are read by code from the VCL (FMX?) linked to your exe. No magic. So the patterns/idioms are the same, just a question of exactly when/where and... hmm... lazy programmer (??).
  6. Bummer, of course, that will be kind of moot. Bummer. You could request a "trustware" licence from IBO (IBObjects) showing similar stuff but then i think FireDAC has all that if you are on Enterprise. No, i'm not surprised (as to why you are not fining resources on line). I'd guess that the component mainly targets "app-local", local memory and such. For the "transport" (SQL <=> Delphi local) i guess you have too look somewhere else. As i said, traditionally what you are after resides [would reside] in the DataController/DataSet layer rather than in the GUI layer. Not sure i'm making myself clear enough here...
  7. DevExpress has something they call "Server Mode" wish is a "GridMode" using "refined" queries. I.e. extended "DataProviders". It is rather convoluted IMHO but it works for specific implementations (it's not a one-for-all). You could check their demos for inspiration.
  8. Hahahahah! Thank you for that "proverb". I have put it in my every-day vocabulary! Brilliant!
  9. Oh, and looking at the pictures, i'm all for one dynamically created form (like Davids first suggestion). Why, because i do not see this as "dialogs" at all. I mean to say that the "form/dialog" way to think may be the least interesting thing about your problem.. My clients' users prefer the search controls to reside in the same form as the result. Like google. A dynamic approach will make it easier to cater for such thisng. But i'm getting way to verbose and should stop. Now.
  10. Looking at those forms / dialogs. That indicates that the user must choose WHAT to search in step 1. Then details in step 2. For your users, would it not be better to have one dialog. User klicks "search" and can then choose WHAT to search on? If user search data is persisted then they could refine the search from last search. Also, maybe some users will want to search on TWO WHATs. IMHO these are the important considerations that should result in a programming strategy. HTH
  11. You mean their "LayoutControl"? Check it out. It's one of the coolest controls out there! (I'm not affiliated).
  12. I must agree with @David Heffernan. This is one idiom/patter for similar stuff. Microsoft do not just do bad things, IMHO lots of times the get things right*. Here' the link i had in mind: https://specials.rejbrand.se/TTaskDialog/ I use it and it can be used to "gauge" the complexity of the result for the path of not inheriting. As i already said, combinations of the two approaches are almost endless in it's permutations. * Visual Code being a good example. File systems under Windows Server (much better that Linux under a lot of circumstances, abundant socket APIs et cetera).
  13. Sounds like the OOP pattern to me 🙂 Seriously, the topic is valid, interesting. But i think that if you want more "concrete" tips, opinions, perhaps write more about what you are trying to do. Perhaps a mock-up? If you are not afraid of information overload, check Marcos Delphi book. IMHO there is a lot of information there that pertains to the topic.
  14. I tend to use a combination of the two above approaches. A base, perhaps some specific 2'nd level. You can also of course "prep" you dialogs/forms dynamically, like the Vista task dialog, setting properties to reflect different cases. What properties/functionality is inherited, dynamically set by properties you expose in the base class is very much up to your needs, i.e application specific. Basically everything you put in the dfm (design-time) will have to be read at form creation and if there are a lot of dynamic changes to what was read from the dfm then the point of reading dfm becomes moot. Personally i tend to avoid things like frames. I also tend to minimise the number of dynamically hidden stuff. Why create 8 frames or tabs with content just to go hide 7 of them after each creation of an instance? when using visual inheritance i often open the dfm's in Visual Code to "keep an eye" of what the IDE is doing, this has helped me understand visual inheritance better too. As mentioned above visual inheritance can get rather messy with a lot of levels.
×