I have a question regarding template parts. I want to create a control that inherits from ChildWindow, but I don't want it to have a border, OK/Close buttons, etc.
Is it an acceptable practice to remove the template parts that I don't want? I have created a copy of the ChildWindow template in Blend and removed the template parts, and it works fine - I just want to make sure that that won't cause any problems down the road.
Thanks,
Charles
If you read some of the custom control development documentation on MSDN it specifically mentions that developers should anticipate that template parts may not exist and code for it, so I think you're Ok there. Personally, when I need to remove template parts I prefer to leave them in the Xaml but set Visibility = Collapsed for something like a button or BorderWidth = 0 for something like a Border. Personal preference I suppose.
Related
I am trying to change the number of custom fields I can create in OrgangeHRM PIM section.
I have found a few articles on this site that say what part of the code to change but non saying where to find the file where the code is stored is in.
If anyone can help then that would be great.
I am running version 4.0 of OrangeHRM.
Thanks
orangeHRM have slots for custom field (i dont remember, but i think 10 slot in orange 4.0), you can use this for put what you need.
Out the box, you can follow guides for add more custom or pre-format fields, but not is more recomendable, this can make broken code.
meanwhile, you think work out the box, remember orangeHRM is a symfony based software, if you know how work symfony (MVC framework), work it whit OrangeHRM is more easy
good luck
I am using Visual Studio Code on my Ubuntu box and when I checked in my code into BitBucket, somehow they are in different alignment, see below.
What would have caused this and how to I rectify this?
Your code almost certainly contains both tabs and spaces for indentation.
When this happens, almost any difference in how tabs are rendered will lead to anomalies such as you've shown above--code that looks right in one rendering looks all wrong in another.
Most code editors include ways to convert the entire file to using either spaces or tabs, but not a combination of the two. Using only spaces probably does the most to guarantee that the code will look the same, regardless of the environment.
On the other hand, using only tabs means that each user will probably see the code as s/he normally views code (at least assuming s/he has his/her environment set up to deal with tabs). For example, if the code is indented with tabs, and you like indentation to be by 8 spaces, but I prefer 4 spaces, each of us can get exactly that from identical source code (i.e., most editors will let us set the tab stops as we see fit).
Select the whole document or the line you have problem with,
Then go to Edit -> Advanced -> Tabify Selected Lines
That should fixed the issue. More info : https://blogs.msdn.microsoft.com/zainnab/2010/03/14/how-to-convert-tabs-to-spaces-and-vice-versa/
I was hopping to have an easy way to customize the display behavior of the Grails fields plugin after reading its docs, but I just realized that it demands an enormous effort as there is no available templates to start from.
I can see the display functionality is hard-coded in FormFieldsTagLib (from methods like renderDefaultInput() ) but I think it is imperative to have the templates themselves (or a way to generate them, somewhat like generating static scaffolding in Grails).
I can see no consistent (and reasonable) way to customize display behaviors for the Grails fields plugin without that. Am I missing something?
Imagine the use case where someone wants to change the boolean default rendering just to display the field label after (and not before) the checkbox, and keep it available to all the boolean fields within its application. Which concerns will he need to handle regarding if the field is required, has errors, prefix and so on? When all he needed was just moving two divs around.
Grails version: 2.5.4, fields-plugin version: 1.5.1
You aren't missing something. You'd have to re-create the existing implementation of each field type rendering in a template for use with the plugin. There isn't a way to generate a file to start with (like scaffolding).
I won't bore you with the historical reason as to why this is the case, but if you do create a set of base templates it would be a good idea to contribute back to the plugin.
I had an issue with the <f:table> tag, and found this post, which led me to find the base or default template inside the plugin repo.
Take a look at
https://github.com/grails3-plugins/fields/tree/master/grails-app/views
That may help you finding some default templates, along with the official doc and this answer on where to put the override.
Hope it helps you.
I noticed something strange, related to the Drag&Drop component from Anders Melander, and I wonder if anybody has an idea ?
I have been looking for the reason, without much success. However the effect is 100% repeatable by simply removing: DropFileTarget->Register(ComboBox); from the project's constructor.
The other day I noticed that the drop down box on my application was not looking right:
Whereas it previously looked (correct) like this:
So I started going back to figure out at what time the look of the component broke and I have now been able to trace the change in look 100% to:
DropFileTarget->Register(ComboBox);
If this line is present, the look is good.
If I remove this line of code from the form's constructor the look of the drop box is wrong !?
I actually wanted to remove DropFileTarget completely from my project since I now use another method to catch a dragged file.
Can anybody please tell me what Register() does here to change the look of the component, so that I can set the look back to what it should be.
My gut says it has to do with theme support as well somehow ?
ADDITIONAL INFORMATION BASED ON THE COMMENTS:
I did some tests. A normal looking Combobox, with theme support, looks like this:
With theme support disabled it looks like this:
In other words, the Drag&Drop component's Register() creates a special look, that I had grown used to, and of which I thought was the correct look.
The canvas where the text is displayed is white instead of grey (default settings).
I'm now torn between going for 'how it should be' or trying to create the look I had gotten used to.
Anybody knows what properties I should change to get the component-influenced look (second screenshot from the top) ?
Firstly, I've done a build, I've done a clean, I've done a rebuild, of both the project and the solution, so that's not the problem.
When I change my model for some reason the intellisense (in fact, it's not just the intellisense as if I do a build it comes up with an error as well) doesn't work. I have a model under ViewData.Model.ContractCostCentre which exists. VS isn't picking this up, at all. Instead, it's referring to an old one which has since been deleted and replaced with the prior one, this is called ViewData.Model.ContractCCList. So in my view I'm having to iterate over a ViewData.Model.ContractCCList despite this not even existing in my *.dbml file.
This isn't the first time I've had this problem, it seems to happen quite often if I change my dbml file (and it's likely to change as we work on highly progressive systems which are always subject to change).
Any ideas?
can you look into your ????.designer.vb or .cs, depend which language you are using
if you don't see that file, show all file in solution
intellisense is using that file
Kezzer,
At the top of your View, there is part of a line of code that determines what model type the page uses. It should look something like this (my example is in c#):
Inherits="System.Web.Mvc.ViewPage<ViewData.Model.ContractCCList>"
Change it to look like this:
Inherits="System.Web.Mvc.ViewPage<ViewData.Model.ContractCostCentre>"