So, I have a form in VB which is visible except when the program is started silently, in which case the form is still loaded but the interactions are done programmatically. However, in a tiny number of cases I want forms created within the invisible form to be visible. What is the best way to accomplish this, ideally without creating new forms. Some ideas I've come up with but really don't like:
Creating a new form, passing that form's hwnd so that it is hosting any applicable windows. Really easy to do, probably pretty flexible. Still ugly.
Calling the visible form manually, pulling out the values, passing the data filled in by the user to invisible form. This solution is probably the easiest, but it's also a hack. It's an awful solution if it was used for more than a tiny number of forms, but it will probably.
Creating a new class, refactoring the forms to be triggered by events.
Setting the main form to be visible, but perverting its load function so that it doesn't actually display anything.
Not using the invisible form at all, refactoring code to better separate functionality of form from usage. In truth, this is largely already true, but I don't see a way to do this completely without some repetition with the way the classes are used, since I'll end up needing to have to different classes which include the same function. Probably the idealistic solution, though.
What I actually ended up doing: Sticking a shell execute call in the affected place which starts a new instance of a copy of the program which was compiled with different flags. This isn't nearly as bad as it sounds. Part of the problem with using any other solution is that ANY time I want to slap a different UI on my code, I need to create a new controller class which handles the relevant events differently. THe majority of the program's interface is already kept separated from its implementation, but creating a new UI requires me to add extra event handlers and whatnot to it. Admittedly it would probably only need about 3 event handlers handle prompting the user for input when events are triggered.
Edit: To an extent, I have mistated my problem: The issue is that I want to recycle part of my existing UI, but not all of it. Thus, making the parts I don't want the user to see be invisible but making the menus that appear visible. Decoupling the individual UI components will probably end up adding additional complexity to the program.
the last option is preferable; after refactoring there should be no redundant code
fiddling with invisible forms is a pretty good indication of the need for refactoring!
I also recommend the last option. What I would do to safely implement with the least amount of changes is as follows.
Make a Backup or check everything into your source control and make a branch.
Make a new ActiveX DLL Project. I would name it some variant of UI_Controller
Note: A new project will force you to identify hidden dependencies within the EXE.
Have it reference everything the EXE is right now.
Have the EXE Project reference the UI_Controller.
Make a class for every major form in the application.
Copy the Minor Dialogs into the UI_Controller DLL.
For each form make a interface class in the UI_Controller DLL (The form will be
implementing this)
Example if you have six major forms you then have six form interfaces and six controller classes
Go through the form for each procedure and event COPY the procedure over to the UI Controller Class and make it public.
Make sure each controller class has an Init procedure.
However there is an exception and that is if the code only deals with other controls and the form. For example Resize event rearranging the code. The reason for this is that is logic specific to that style of form. A different form or UI using the controller class will have a different resize algorithm so it makes no sense to move that code over. You will have to use your best judgment.
Go back to the Controller classes. Many of the procedures will need to reference elements on a specific form or fire events on a form. Write a subroutine header or function in your form interface class to allow that event to occur or retrieve the needed information.
Note that if you find the same actions grouped together or the same series of information retrieved considered making just one subroutine instead of multiple.
Change any direct references to a form to a call on the interface.
Have your major forms implement each interface. Make a GlobalMultiUse Class in your UI Controller DLL that allows the EXE to register each form with it's controller. The register subroutines should only accept an object of the form interface. In your application initialize have pass each major form to the correct registration function before you do anything else.
Run your project and correct any errors. Note that the actual function of your software should remain the same as you should have only been copying and implementing.
When the software runs without errors. Check it into your source control or make a backup.
Start replace each procedure of ONE of your major forms with a call to corresponding method of your controller form. If any other form calls something on the form you are working on switch that call to the controller.
When you are done make sure the controller form initialization is called in your application initialization section. You make need to switch to using a Sub Main for this to work.
When this works properly work on another form. Keep doing this until all forms are converted.
Clean up anything that is not used.
Test and if it passes you are done.
What you have now is an application where you can rip off the current UI and replace with anything that implements the form interfaces. So you can have a invisible EXE, a unit test EXE, and your regular EXE.
You will have to decide what best for you based on the complexity of your application. You can have a partial conversion where you only give one or two forms a controller class.
Related
I have written python code that analyses two text sources and compares them.
I'd like to implement this dynamically via two text boxes that a user could either type into or manually upload. I have already begun coding this using HTML. Would it be better to implement a widget or the models instead to make the text area boxes?
Edit:
I wrote this question when I was just figuring Django out, so forgive me if it sounds confusing. But everyone starts somewhere. I'm unable to delete the question as contributions have been made already. YouTube courses proved helpful in learning the basics, if any beginners stumble upon this.
You use a form object. Django has form objects (https://docs.djangoproject.com/en/2.0/topics/forms) that take a model and translate it into html elements. So I guess in a way, you implement the model but I want to stress that that's not actually what's happening from a technical standpoint. A better way to say it is that you're implementing forms. The reason I stress this so much is so that you understand what's really going on so that you don't have misunderstandings that end up costing you in code clarity and readability.
So to answer your question, you can implement django forms to do this very easily. The way you implement it depends on your models and how they are designed since the forms use the models to create the right html form elements. If you're dealing with one model that will be instantiated by the form input, create a model form. This will take the input from the form and create your model instance. If you're dealing with one form that uses multiple models, then use a generic form. In this case, you will have to write your own save method that does the actual logic of the form.
One other thing to add... No matter what, your end result will always be a widget on the HTML in the end. Django forms translate a model class into a form element with input elements. If you didn't use Django forms, you would still do the translating, but you would have to do it from scratch.
I hope this helps and that I correctly understood your question.
I have a form that normally works with respect to dirtyforms. However, there is one circumstance where a jquery-ui datapicker calendar will pop up the "are your sure" dialog when a date is clicked.
I emphasize that this normally works correctly. The situation is related to the initial conditions of the form data source. Things work when the object being referenced is existing, but not if it is new. So I am sure somewhere there is a difference in the initial conditions of the form. But in theory the form should be identical.
How can I find what is causing the popup so I can fix my issue?
Well, I did find what was causing my problem by comparing the HTML of the working and non-working situations. (Not an easy task since there were many non-relevant differences.)
Seems that the original coder did a strange thing. Left out some Javascript function declarations when the page was "new" but of course did not eliminate the calls on those functions.
So I guess that the javascript errors were the root cause. At least when I include those function declarations everything works correctly.
By default, most anchor links on the page will trigger the dialog. We don't have a hard-coded selector of all potential 3rd party widgets, you must manually take inventory of whether these widgets use hyperlinks and ignore them if they are causing errant behavior.
See ignoring things for more information.
I was unable to reproduce this behavior using Dirty Forms 2.0.0, jQuery UI 1.11.3, and jQuery 1.11.3. However, in previous versions of Dirty Forms, you can probably use the following code to ignore the hyperlink clicks from the DatePicker.
$('.ui-datepicker a').addClass($.DirtyForms.ignoreClass);
I am writing a helper class to query my Zenfolio feed, return and display the images. Right now this code is split between a viewmodel and code in my controller. I want to pack it up into a helper class. Would all the code go into the helper or do i still split the code among different class with the helper only responible for generating the html? I have googled but not found an answer to my question.
Within the MVC pattern there is a clear separation between Model (data), View (html) and Controller (what gives the Model to the View).
To answer your question, No. Load your models in your Controller. Display them in your View. Html Helpers should only generate html for your view.
You may want to consider using a DisplayTemplate, which allows you use the same View template for every model of a particular type.
I wouldn't do any data access from the view. This sounds like a good use case for an action, and reusing code via the RenderAction method. You can mark the action as a child action using the [ChildActionOnly] attribute, which ensures it can't be invoked directly from the HTTP request, and return a PartialView result.
HTML helpers should really be used to generate HTML tags from data taken from the ViewData or Model (i.e. your view model in this case).
Data access in an HtmlHelper is only pain.
I've had the misfortune to inherit a project that had ad-hoc SQL placed into the HtmlHelpers by the 2nd developer on a project. The HtmlHelpers were beautifully written by the first developer, and the ad-hoc SQL pretty much nullified all of the time and effort put into having an service oriented architecture, having an ORM (the 2nd level cache became worthless), the unit of work pattern(transactions, worthless), and every aspect of design. Eventually, this 2nd developer had to make larger and larger HtmlHelpers so that different elements could share access to the data.
This was originally done for a display mode, and editing was accomplished through a pile of ugly custom javascript. All told, when the page rendered, it made 600 synchronous calls to the database.
I've created a derived WinForm textbox control that knows how to provide a hint (those grayed out words that say things like "Password" or "Enter search here") as well as allowing for the beep on enter to be disabled.
I have two public properties BeepOnEnter, and HintText, a single method - ResetHint and then overrides for the Text property, the OnGotFocus event and the OnKeyPress event.
This code works fine until I have a need for a textbox on a tool strip also known as a ToolStripTextBox.
I'd like to use the same code for both the TextBox AND the ToolStripTextBox. Is there a way minimize/reduce redundancy? I definitely need code that has classes that are derived from TextBox and ToolStripTextBox so the ui designer allows me to drop these new controls on a form or tool strip but can't figure out how to do it in an OO way.
ToolStripTextBox is derived from ToolStripControlHost and TextBox is derived from TextBoxBase and as multiple inheritance is not allowed, you will be best off creating a 3rd utility class and putting all similar functions in it. You can then leverage an instance of this class in your derived controls to get the common functionality you want.
what magento frontend events can should I observe if I want the chance to inject blocks to the ("head" block) ?
and while in the observer's code, how do I check if the current layout has some handle (e.g. not_logged_in) set.
Give the
controller_action_layout_generate_blocks_after
event a try. The Layout object and its child blocks should be instantiated by the point that event fires.
There's only ever one Layout object, and you can grab the handles in play with
// get the layout->get the updates manager->get the handles
$handles = Mage::getSingleton('core/layout')->getUpdate()->getHandles();
var_dump($handles);
If you're working on front-end code and trying to stick to magento conventions, it's probably better to add a layout.xml file to your module, and use the layout file to add your blocks. It's less fun than figuring out something new though!
I appreciate the plug on the blog, but clockworkgeek is correct. The best way to accomplish this is to use a layout file to add the blocks you need. It is also possible for those blocks to change their own rendering behavior based on arbitrary code.
If there is a reason why you cannot use layouts, please elaborate a bit in your question and we'll be happy to help.