anyone know how to edit the password meter from prime-react ? they only give like weak medium strong I need more than that. I haven't tried anything
the short answer is that you cannot. There are only 3 states weak, medium and strong and they have labels that can be updated if you don't like those terms you can use weakLabel etc to define your own text and your own regexes to determine strength.
See the properties available at the demo page: https://primefaces.org/primereact/password/
Related
when several Language Servers are providing document symbols. They are both displayed in Outline. It seems that the "displayName" of the extension is used to separate the 2 outlines.
Is it possible to provide a specific name?
I would like to provide a shorter ones that the extension display name to improve readability of the outline.
The current outline view looks alike this, cropping names by default as it is too long:
it wasn't possible. But it might be implemented soon: https://github.com/Microsoft/vscode/issues/62839
I am not able to understand what is the difference between these two keywords in swift3?
If anyone has a link to a good article about this, please share.
There is no difference conceptually; moduleprivate was just a possible alternate name for the same access level that didn't get accepted during discussions about access control modifier naming.
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160328/013854.html
The internal modifier is the only one of the two that actually exists in the Swift language, but the two names represent the same behavior.
I'm struggling with the size of output files for large Modelica models. Off course, I can protect some objects in order to remove them completely from the result file. However, that gives rise to two problems:
it's not possible to redeclare protected objects
if i want to test my model in detail (eg for a short time period), i need to declare those objects publicly again in order to see their variables
I wonder if there's a trick to set the 'verbosity' of a Modelica model. Maybe what I would like is a third keyword next to public, protected, eg. transparent. Then, when setting up a simulation, I want be able to set the verbosity level to 1, or 2 with the following effect:
1--> consider all transparentelements as protected
2--> consider all transparentelements as public
This effect would propagate to all models and submodels.
I don't think this already exists. But is there an easy workaround?
Thanks,
Roel
As Michael Tiller wrote above, this is not handled the same way in all Modelica tools and there is no definite answer. To give an OpenModelica-specific answer, it's possible to use simulate(ModelName,outputFilter="regex"), to store only the variables that fully match the given regex (default is .*, matching any variable).
Roel,
I know several people wrestling with this issue. At the moment, all of this depends on the tool being used. I don't know how other tools handle filtering of results, but in Dymola you control it (as you point out) by giving the signals special qualifiers (e.g. protected).
One thing I've done in the past is to extend from a model and then add a bunch of output signals for things I'm interested in. Then you can select "Outputs" in Dymola to make sure those get in the results file. This is far from perfect because a) listing everything you want can get tedious and b) referencing protected variables is not strictly allowed (although Dymola lets you get away with it but issues a warning).
At Dassault, we are actively discussing this idea and hope to provide some better functionality along these lines. It isn't clear whether such functionality will be strictly tool specific or whether it will involve the language somehow. But if it is language related, we will (of course) work with the design group to formulate a specification that other tool vendors can support as well.
In SystemModeler, you go to the Settings tab in the Experiment Browswer in Simulation Center. Click on Output on the bottom and select which variables to store.
(The options are state variables, derivatives, algebraic variables, parameters, protected variables and if you mark the Store simulation log-option, you'll get some interesting statistics on events over time and function evaluations, opening another possibility to track down parts of the simulation and model that creates more evaluations)
I am not sure if this helps you, but in Dymola you can go to Simulation->Setup->Output and mark a checkbox saying "Store Protected variables". That way it is possible to declare most variables as protected: during normal simulation they are not stored, but when debugging your model, you just mark that checkbox and they are stored.
Of course that is not the same as your suggested keyword transparent, but maybe it helps a little...
A bit late, but in Dymola 2013 FD01 and later you can select which variables to store based on names (and model names) using the annotation __Dymola_selections, and even filter on user-defined tags - so you could create a tag name "transparent" in the model. See "Matching and variable selections" in the manual.
As the iPad app I am making has been growing its size, it is hard for me to keep track of UI design values. Here, I am talking about values such as a table's width, background colors, and a title's font.
I would like to organize all UI design-related values and objects more efficiently.
How do you organize these?
Do you #define values in a header file?
Do you declare them as global variables or not?
Do you put your values one static class?
Or do you think not-organizing these values is rather better?
I would like to hear your advice.
Thank you :)
Yes it depends, therefore just some rules of thumb...
Do you #define values in a header file?
...in cases where I might want to change this locally only, eg for constants, colors, alignments, button images, ... the main reason why I do this however is the documentation it allows by giving the local defines a long explaining name
Do you declare them as global variables or not?
...an all my apps I have a MainDataManager Class, that holds all the variables I need globally - for the UI part often I have my own globally used object. This is extremely useful, simplifies the code, and probably one of the most important things I learned early on. might also see here Using Variable of AppDelegate as a Global Variable - question regarding release/retain
Do you put your values one static class?
...static classes exist kind of conceptually. Static variables are quite useful when you want to give a method some kind of memory of its own. However, none plays an important role in my UI.
In general, I like to use IB to layout the screens but set all the button names, labels, texts in the code. Why? Because when I have to localize the app maintaining multiple XIB files (for each language there will be one isolated XIB file to maintain) becomes a real burden even if there is only one single change in the layout.
All the global constant settings are always kept in GloblDefinitions.h while at the same time I have in my .pch file this entry #import "GlobalDefinitions.h"
So the combintation of a delegate variable provided globally + GlobalDefinitions.h for constants is my solution.
Its a good question. When combining use of interface builder with hand-coded UI tweaks and/or custom components you also have the problem of duplicated values between IB and code.
In some situations, for readability and for easy adjustment by a third party its easier if values are just hard coded in-place - so in trival cases (e.g. cases where the value is not repeated anywhere else or is unlikely to change) this might be a valid option.
In general, if the constants are specific to the layout of a particular UI component then it seems to make sense to #define them in the header file for the UI component that uses them - I think putting them all in one global file breaks the decoupling that you'd like to have between user interface components, and also for readability it can be easier for another dev to find them in the header file.
On the other hand if there are values that are used consistently across multiple UI components within the one application, then these can be defined in a global include file. Similarly if there are 'base' values that are used to derive other lengths etc. that are used commonly across multiple UI components these also can be stored in a global include.
Also whereever possible make use of the layout manager margin flexibility settings and width/height flexibility settings to minimise the need to hard code values. And when relevant, derive values from a base value or a system value (e.g. screen width).
At the end of the day if the value is there in code in front of you sometimes that much easier to figure out and tweak than changing a #define off in some other file - on the other hand - if the same value is repeated in multiple places and a #define is not used, then it can be very confusing for another coder to come in and change one of these repeated values only and try to understand and sift through the resultant side effects and which other places the value should be changed.
Well Ryan that depends upon you..
You can either use pre processor directives..
declaring in .pch file.
or you can either make an object class taking all the constants....
Hope that will help you..
Thanks
This is what I have learnt from few of my previous projects.
1] Naming conventions - use appropriate and standardized prefix. ex tblRecordLis, viewControlPanel etc.
2] Keep Constants together - keeping all constants at one place reduces the pain of searching entire project to find/fix/replace constants and their values.
3] Grouping relevant Classes together according to utility and their functionality.
4] UI constants like size, offsets , frame values (Which you need to hard code) can be kept in constants
a few which I used are
#define MenuPopoverFrame CGSizeMake(278, 550);
#define LandscapeContentSize #"{{0,0},{719,734}}"
#define PortraitContentSize #"{{2,0},{765,980}}"
5] Using IB as much as possible as it gives us more flexibility.
6] PROPER commenting and documentation proves to be a life saver when dealing with debugging.
I find it easy to declare keys as constants as using them at multiple places also increases the chances of error if used as such. eq key named #"method" can be better declared as
#define kMethodKey #"method"
This very simple thing saves my time while debugging when the project size grows larger.
** Taking hints from Apple's samples also gives you a great help in keeping your code standardized.
I'm interested in developing a natural language command language for a domain with existing rules. I was very impressed when Terry Winograd's SHRDLU showed the way (the conversation below is 40 years old! Astonishing). Can we do better now and if so where can I get examples?
Person: Pick up a big red block.
Computer: OK.
Person: Grasp the pyramid.
Computer: I don't understand which pyramid you mean.
Person (changing their mind): Find a block which is taller than the one you are holding and put it into the box.
Computer: By "it", I assume you mean the block which is taller than the one I am holding.
Computer: OK.
Person: What does the box contain?
Computer: The blue pyramid and the blue block.
Person: What is the pyramid supported by?
Computer: The box.
Person: How many blocks are not in the box?
Computer: Four of them.
Person: Is at least one of them narrower than the one which I told you to pick up?
Computer: Yes, the red cube.
I have an ontology for the domain so can reason over common problems.
Take a look at OpenCyc, a general knowledge base and commonsense reasoning engine.
Take a look at the controlled English (ACE) that has been developed in the Attempto project.
It seems to have the required expressivity and flexibility.
The ACE parser parses ACE sentences into a first order logic formula (a variant called DRS) which can then be used for further processing, e.g. automatic reasoning.
The parser is available under LGPL, see the demo here.
I have also just encountered Regulus (http://en.wikipedia.org/wiki/Regulus_Grammar_Compiler) which has been extensively used by NASA.