Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.5K Microsoft Dynamics NAV
- 18.5K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 264 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 992 SQL General
- 385 SQL Performance
- 33 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Options
Simulate Button Click
msraetsen
Member Posts: 8
Is there any way to simulate a click on a button through code?
Basically what I need is the following:
On the Job List the OK button's PushAction is LookupOk. I have another button Sort (on the Job List form) that (on its onPush Trigger) run's some code first, then if it changed the current record on the Job List, I need to close the Job List Form with LookupOk.
I can't figure out how to return LookupOk without having to use the PushAction property of a control (which will not work in these circumstances becauses it causes the form to exit immediately, but I need to execute the code first).
Any Ideas?
Thanks,
Mark.
Basically what I need is the following:
On the Job List the OK button's PushAction is LookupOk. I have another button Sort (on the Job List form) that (on its onPush Trigger) run's some code first, then if it changed the current record on the Job List, I need to close the Job List Form with LookupOk.
I can't figure out how to return LookupOk without having to use the PushAction property of a control (which will not work in these circumstances becauses it causes the form to exit immediately, but I need to execute the code first).
Any Ideas?
Thanks,
Mark.
0
Comments
Try the following:
1. Assign a shortcut key to the button you want to auto click. (in this example it is CTRL+m)
2. create automation variable to 'Windows Script Host Object Model'.WshShell and call this variable wscript
3. at the place in C/AL you want the button to be clicked insert following code:
CREATE(wscript); wscript.SendKeys('^m'); // stands for CTRL+m CLEAR(wscript);This application will send the combination CTRL+m to the active window. Note that you have to use these keys for other combinations:
SHIFT = '+'
CTRL = '^'
ALT = '%'
Look in MSDN for more info on sendkeys. (lot of fun stuff you can do with that
Hope this helps!
Then use the following code on the OK button (and remove lookupok property):
IF <condition> THEN BEGIN wscript.sendkeys('^m'); END ELSE BEGIN OtherForm.LOOKUP(); END;Or did i now completely misunderstood you?
It only seems like a clunky solution for something that was omited in Navision. This is one of the things that another developer looks at a few months later without understanding what it does.
I believe that the code should be the documentation itself, but in this case that's impossible.
Another concern is that wsShell is an ActiveX component that I'd rather not use because of all it's security implictions.
Then call this Function from the OnPush Trigger of the CommandButton.
Now you will be able to use this new Function from wherever you want/need to.
Sorry wrong topic :oops:
Documentation for Microsoft Navision
E/R diagrams, Workflow diagrams, UML diagrams, process diagrams
Moving the code to a Function/Procedure does nothing to make the code itself more comprehensible, it only is now contained in something we can give a name. Off course that name can not be very long as the Navision IDE does not allow functionnames of any meaningfull length (theHorrorOfHvngToUseAbbrvtns).
And there is another problem.
This code is supposed to click a button on a form. Unless that button is there and has the correct shortcut-key, the code won't do anything at all, it won't even give an errormessage. Even worse, if the shortcut-key was assigned to another button it could do very strange things.
And there is no way to add that button to the form at runtime, so the Function cannot control it's own dependencies.
This is one of the reasons why I don't like Navision, you are not in control.
It was convenient and easy that when a button is declared as a LookUpOK button it closes the form and returns ACTION::LookUpOK, but as soon as you want to go of the predefined path you're left to all kinds of clunky solutions. I't like the Wizard of Oz. As soon as you wander of the yellow brick road, you're lost. If the yellow brick road does not lead you to where you need to go Navision requires you to restate your goals. In this way Navision defines the business, instead of that the business defines the ERP functionality.
By the way JanPieter, I do value your contribution, it just frustrates me that after 9 years of serious software development I have to code things like sending keys to hidden buttons because the environment I need to work in is so limited and nobody seems to mind that.
And I don't mean just saying that you want it to run the code behind a button, I mean the business procedure you are trying to adjust Navision to.
Thank you.
On an Invoice you can put Shipment Lines. This goes through Form 5708 Gte Shipment Lines. One selects some shipment lines and clicks on the OK button. The Shipment Lines are created as invoice lines when you click OK and then the form closes.
However, if those Shipment Lines have Orders where some settings (like Payment Terms Code, ...) are conflicting (meaning ShipmentLine A has an Order O1, ShipmentLine B has an Order O2, and their Payment Terms Code differs), then when clicking OK the from should not close but another modeal form should be shown asking the user which settings are to be used for the Invoice. Because the OK button on F5708 has a PushAction LookUpOK, the form tries to close itself without waiting for the code in the OnPush trigger to execute. Because that code pops up a Modal Form, we get a runtime error. The solution is to remove the pushaction LookUpOK so the form does not close by itself, perform the needed actions in code and call CurrForm.Close at the end. However, in the calling Invoice form I no receive an ACTION::LookUpOK result because I no longer have a LookUpOK button. That is the reason I want to be able to return that value througth code.
There are workarounds, I could set some variable on the calling form, I could use a hidden button, but al of these are workarounds for the fact that I cannot return ACTION::LookUpOK from code, so I cannot code a simple elegant solution, I need to jump through hoops to get this done.
I read it so often here and completely do not understand. Why? You write a three or four lines explanation into the Documentation trigger and everything is clear for everybody.
I could never understand the pains people take to do things that do not have to be explained instead of explaining them...
Do It Yourself is they key. Standard code might work - your code surely works.
... and TheHorrorOfUsingJavaOrDotNetStyleDamnLongFunctionsOfSomeElse? Who has time for it? We rarely have more then fifteen minutes for doing a change. As I always say: documentation. My functions are called like CNREPOI which means Create New Reservation Entry Pair On Inventory. It is documented right in the function definition, and in the Documentation trigger of the object, and in an external file extracted from the doc trigger by a script.
Everybody who does not read documentation before changing anything deserves what he gets.
(This is why I hate Java and .NET culture, people always forcing each other to type half screen long stuff. In the Python culture, which I love, there is a documentation comment for every function and object which is extracted into an autogenerated documentation - that's the place to write long explanations.)
Do It Yourself is they key. Standard code might work - your code surely works.
On the other hand, if you can write code in a clean, elegant way, there is no need for documentation, becuase the code *is* the documentation.
The other problem with documenation is that sooner or later somebody changes the code without changing the documentation, which is actually worse than having no documentation at all.
The basic fact remains, if you have ever worked on a serious project in a serious IDE, developing in Navision feels like setting the clock back two decades. And please, don't give me that 'Navision was not made for developing' thing, it has an IDE, it has language, and NSCs sell it as a customizable solution. Customizing means for our business that a lot of the standard functionality needs to be replaced or altered, so I do call this developing. If it was only intended that you once in a while change some label on a form, NSCs should be prohibited to sell it as a fully customizable solution.
the interesting thing is that although Navision was deeply in the Microsoft culture even well befor the acquisition, their programming culture is more similar to Open Source, f.e. Python culture - Microsoft / Sun Java culture is optimalised for "it's just a job" - type of programmers, all those tie-wearing types who don't want to memorize the full code base of a project, while OS culture is optimalized for "hackers" in the good sense. It needs a certain kind of fanatism. It does not mean obfuscated code of course, but not too much explanation is necessary for hackers. I did not intend it as an offense, so please don't take is as one
(Actually, consultants turn into better C/AL programmers than those people who grew up on Visual Studio or Delphi .. )
Do It Yourself is they key. Standard code might work - your code surely works.
With modern projects, it is simply impossible to have the complete codebase in your head. And anyway, there is no point to have the complete codebase in your head, because if you code the correct way, everything is neatly componentized so that you hardly have any side effects of your code.
I doubt that C/AL coders are 'hackers'. A real hacker would turn with a lot of frustration given the tiny sandbox that Navison let's you play in. C/AL holds your hand even more than VB6 did, and that language/environment did not have a good reputation among 'hackers'.
The only 'hacker' quility you need as a C/AL coder is indeed a cretain kind of fanaticism, because things that are unambiguous and immediately clear in a.NET or Java project are hidden behind functions that span multiple pages, a zillion global variables and a crappy IDE. People on my team are indeed no real C/AL fanatics. We do it because we have to, but if it were up to us we would dump Navision right away.
Well off course. I think that a COBOL programmer would be a better C/AL programmer too than a .NET programmer. About which environment that says the most I leave up to the reader. Put all three of them on a timeline; it'll become clear.
Just to make sure that I'm not misunderstood. Navision does have it's place in ERP land, as long as you're willing to adapt your business to fit in Navision instead of the other way around. For us, any ERP tool would be a bad choice because we do something so specific that we can't adapt our business to Navision.
And while the functionality of Navision may be adequate, the while C/AL experience is a disaster. No modern language, no modern language constructs and the code written by Navision itself is utter unreadable crap (and I really mean that).
The whole User Interface framework is poorly architected (of which this Button Click thing is an example) and the IDE is a sorry excuse for an IDE.
So from a developers perspective, working with Navision is like being a carpenter when all you have is Swiss Army Knive. If you've never had any other tools, it seems OK to you, but once you've worked with proper carpenting tools, you'd never want to go back.
Navision have tools for the work for which is created - fast customization of the ERP system. If it is uncomfortable for you, it does not say anything about if it is good or bad. Do not forget time, when the whole system was created. And the simplicity of all the things is the way how to keep the customization simple and fast. Of course, some things can be better. Yes, it is your opinion and I do not want to argue with you... but in many cases of missing functionality of C/AL etc. is not main problem "how to do it?" but "do I need to do it?" In many cases it is something that customer want but it is not connected to the ERP, but only to "visual look" or something other. For collecting data, transformation of this data and reporting the data, it is all enough.
It will be better to have two environments - one simple for all the developers which do not need system which is thinking instead them, and one for Visual Studio users, to have feeling that they have all what they need... but the road of developing the system is long and we will se, what is prepared for us...
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
(Which is going way off-topic)
I think that c/al is more a customisation tool than a development environment, so comparing it to Visual Studio is unfair, I believe.
I agree with Kamil, and we will see what the future brings us.
As for the future... who knows, and I will leave it at that, right Kamil \:D/
RIS Plus, LLC
MVP - Business Apps
Ignoring problems is not going to solve it. As long as all the Navision users don't complain, nothign will change.
By the way, I just asked the original poster if he had a solution for a problem I have too (by the way, I posted this in some other thread). Then janpieter posted a solution which is to me an ugly hack because the Forms framework does not support a corect solution. But boy, if I dare to say that (sorry, this messag egot posted before it was finished) I get to hear all the complaint written above. Sure, is is possible to keep your engine runnign with a stocking, and if you have nothing else, that will do. But i'd rather just have the belt replaced because that is the proper solution.
I think you are being correct in saying that c/al (or the IDE) is more of a customisation tool than a development tool. Unfortunately, the NSC that sold Navision here did not say that, they sold it as an alterable, adaptable, developable solution. I think MS should do something to get ris of these rotten apples, because in the end, nobody wins. The NSC does not win (they are bankrupt now), Navision does not win because it becomes unupgradable when doing this, and we do not win because we are fighting a lost cause.
As an NSC, I have to react about this : Yes, we propose to the Customer to take a Developper Licence if he wants, but we clearly define the limits of the available tools and give them appropriate training. If your NCS sells you the solution with the argument that you said, I think their actual situation is not a surprise ... But don't take general conclusion due to one bad experience ...
Another think, Navision gives you the opportunity to work with customized external process (from C/FRONT, XML, ...) so there is no closed doors ! Also, some exotical demands of customers could not be achieved, but they have the same problem with Word or Excel and nobody complains ... Be honnest, don't ask the system to make all the dreams (but I know that some dreams are more Needs than Wishes). Personaly, I hope Navision could make one day my first morning coffee mug ... in version 5 ?