At MSChart when using at chart1 and do things now i use chart1.BeginInit do stuff and use chart1.EndInit, I don't know if this is needed and i even don't have a clue what is correct usage of chart1.Begin and End Init in general
Can Anybody "clarify"/ tell about When to use Or simply never use BeginInit and EndInit routines of chart1 would be helpfull ?
Thanks
BeginInit and EndInit are related to the ISupportInitialize Interface, and you can read about this at
http://msdn.microsoft.com/en-us/library/system.componentmodel.isupportinitialize.aspx
Also do an all file find for BeginInit for the MSChart example project.
It's mostly for setting many properties that are dependent on each other or prevent a potential over-load of paint messages or internal logic confusion from many property settings. Think of it like a better way of setting all control Visible properties to false, making adjustments, and then setting control Visible = true.
If you don't have a problem to solve by implementing these methods, I would not use it. Else model your use from the mschart example project.
Related
Tailwind offers a feature where you can give an input element the peer class and then, in a sibling element use the peer-invalid: pseudoclass to apply conditional stylings. This is commonly used to provide helper text when a form field is not valid.
I don't see how this can be tested in JS-DOM though, as JS-DOM doesn't have access to the actual CSS when it is just rendering components in unit tests.
The information I have seen about getting JS-DOM to use CSS at all is kinda sketchy, so I was wondering if it's even worth trying to get it to evaluate a bunch of tailwind classes in a NextJS/Jest/RTL project. I'm using Tailwind 3 so it's not even like I have a big file full of generated classes I could try and pass to JS-DOM :/
So can it be done? (Note the hard fact please mods!!!)
(And, somewhat more subjectively, should it be done? Or is there a better way to approach this?)
I am using APEX 20.2.0.00.20. apex.region(region_static_id).widget() method should return a jQuery object according to the documentation. I am trying to figure out how to know what the object's properties and methods are, especially when they are not mentioned in the documentation. I tried running apex.region(calendar_region_static_id).widget() to return the object and inspect what properties and methods it has but I got S.fn.init [div#CAL_calendar.fc.ui-widget.fc-ltr, prevObject: S.fn.init(1)] 0: div#CAL_calendar.fc.ui-widget.fc-ltr length: 1 prevObject: S.fn.init [document] __proto__: Object(0)
I did not get the object. I do not know what s.fn.init or the rest of the returned code is?!
I see code like apex.region("calendar_static_id").widget().fullCalendar("getView"), so I assumed I should have gotten the jQuery object which has the "fullCalendar" method and more when I ran apex.region(calendar_region_static_id).widget(), but I have not.
Is this not the right way to inspect a jQuery object's properties and methods?
APEX integrates the FullCalendar widget, but it doesn't duplicate its documentation. Have a look here for a list of the FullCalendar methods and options.
In general, most (interactive) APEX regions are implemented as jQuery UI widgets. That means you can use them like this:
$('selector').widgetName('methodName'); //invokes said method
$('selector').widgetName('methodName', 'param1'); //invokes said method with a parameter
$('selector').widgetName('option', 'optionName'); //gets a specific option
$('selector').widgetName('option', 'optionName', 'newVal'); //sets a specific option
What's more, you can inspect all available options by running:
$('selector').widgetName('option');
And even have a look at the internal object, see all methods, public and otherwise, via:
$('selector').widgetName('instance');
Moreover, via its region interface, APEX offers an even easier way to reach those methods and options, even without having to know a region's widgetName:
// this
$('widgetSelector', 'staticId').widgetName('methodName');
// is equivalent to
apex.region('staticId').widget().widgetName('methodName');
// is quivalent to
apex.region('staticId').call('methodName');
The last way is the shortest and doesn't require knowing the real widget's id or widget name.
All of this helps when dealing with regular APEX widgets, such as the Interactive Grid.
apex.region('emp').call('instance'); //inspects all methods
apex.region('emp').call('option'); //inspects all options
This however does not work on the FullCalendar region, for reasons that are beyond me. It should help you navigate all other APEX regions, but for the FullCalendar you'll have to resort to their API docs.
Hope this helps a bit.
I'm trying to make my own full adder and some other devices as a sub-circuit in "Proteus" and use them several times in a bigger circuit.
The problem is when you copy a sub-circuit you need to rename all of its inner parts, otherwise, the parts with a same name in two sub-circuits would be considered as one, therefore you'd get some errors.
So I'd like to know if there is a way to define a full adder of my own and use it like "74LS183" which is a primitive device, and by primitive I mean it has been defined in the library.
From answer posted here
It's in the Proteus Help file:
SCHEMATIC CAPTURE HELP (F1) -> MULTI-SHEET DESIGNS -> Hierarchical Designs
See the section "Module Components":
Any ordinary component can be made into a module by setting the Attach Hierarchy Module checkbox on the Edit Component dialogue form.
The component's value is taken to be the name for the associated circuit,
and the component's reference serves as the instance name.
after this you can use your new implementation of that component with your new name. for making it available at library see "External Modules" section of proteus help.
The problem with copying is solved in "Proteus 8".not completely but sort of.
I mean you can copy a subcircuit without a need to change it's inner parts, but you must change the subcircuit name and I mean the bigger name above the subcircuit not the little one below it.
so there is no need to define a primitive.
My problem is the following: For a while now I got used to encapsulate a few (the most relevant and reusable) queries of my application in properties within my Django models.
to do that, I constantly do:
from my_app.models import ModelBla
.....
class ModelBlehhh():
#property
def some_bla_things(self, bla):
return ModelBla.objects.filter(.....)
I have always considered it to be good practice, and I use most of them a lot throughout my applications.
The problem is: These imports that are being used mostly for querying are stating to get in the way of my models' relations structure. Meaning: It's becoming more and more frequent that I cannot create properties for querying without creating circular import issues.
Is my approach correct? Is there a better way to encapsulate these queries? What do you usually do?
Thanks for your help.
I don't see why you need the properties at all, let alone the imports.
If you're filtering some other model based on the current one, that must mean you have a relation to that model. And if you have a relation, then you should be using the automatic backwards relation. So rather than SomeOtherModel.objects.filter(blah=self), you should be doing self.someothermodel_set.all().
Is there a better way to encapsulate these queries?
Actually, you shouldn't let the circular dependency eat you, go removing it up instead. This will increase your access to the database in the later stage of the project.You can remove the circular imports by redefining your structure at this stage only , otherwise it will be too late to refactor and correct where you were wrong.
What do you usually do?
Basically, it is not what others do.It depends on what your application is scoped of. If your application is long term app, then what you are doing is wrong. Just make a repository kind of thing which will be available to all the code and the code can access it whenever needed without any circular imports , that is without any dependency.
Im currently using ie as an active x com thing on wxWidgets and was wanting to know if there is any easy way to change the user agent that will always work.
Atm im changing the header but this only works when i manually load the link (i.e. call setUrl)
The only way that will "always work," so far as I've been able to find, is changing the user-agent string in the registry. That will, of course, affect every web browser instance running on that machine.
You might also try a Google search on DISPID_AMBIENT_USERAGENT. From this Microsoft page:
MSHTML will also ask for a new user
agent via DISPID_AMBIENT_USERAGENT
when navigating to clicked hyperlinks.
This ambient property can be
overridden, but it is not used when
programmatically calling the Navigate
method; it will also not cause the
userAgent property of the DOM's
navigator object or clientInformation
behavior to be altered - this property
will always reflect Internet
Explorer's own UserAgent string.
I'm not familiar with the MSHTML component, so I'm not certain that's helpful.
I hope that at least gives you a place to start. :-)
I did a bit of googling today with the hint you provided head geek and i worked out how to do it.
wxWidgets uses an activex rapper class called FrameSite that handles the invoke requests. What i did was make a new class that inherits from this, handles the DISPID_AMBIENT_USERAGENT event and passes all others on. Thus now i can return a different user agent.
Thanks for the help.
Head Geek already told you where in the registy IE will look by default.
This is just a default, though. If you implement [IDocHostUIHandler::GetOptionKeyPath](http://msdn.microsoft.com/en-us/library/aa753258(VS.85%29.aspx) or [IDocHostUIHandler2::GetOverrideKeyPath](http://msdn.microsoft.com/en-us/library/aa753274(VS.85%29.aspx), IE will use that registry entry instead.
You'll probably want to use SysInternal's RegMon to debug this.