Related
reposted to Dev&Hack forum Aug 9th, 12:30pm PST
I'm not a developer, and only an intermediate(?) VBA programmer for my own solutions. (Though several of those are quite involved.)
I have a question that I'd like to post on the Developers forum, because I believe it falls in "their" wheelhouse.
I've read and respect the posting guidelines published for each forum and the site generally.
I've done my web search diligence, and have posted inquiry on other sites specific to my device and the particular application(s) involved. No luck.
Am requesting permission/blessing to post the following:
Keystrokes as code?
Specifically Excel Mobile keyboard shortcut Alt-PgUp/Dn
I've created several Keystroke "routines" to minimize stylus use in Excel Mobile. I've mapped to hardware buttons, and they all work great... except Alt-PgUp(and PgDn). In Excel, these key combos will scroll one screen left or right, respectively. Other similarly-coded "routines" work as expected.
I've worked around this for now by recording screentaps in Excel's horizontal scrollbar. Unfortunately, the location of that s/b depends on whether SIP is active. If it is, the vertical co-ordinates of the screentaps become irrelevant and/or potentially destructive to my intended result. I prefer to avoid "position dependent" commands whenever possible for obvious reasons.
I have several other programs at my disposal to effect the Alt-PgUp/Dn shortcut(s).... IF I knew how to define the values(?) of Alt-PgUp/Dn in a script.
(MortScript, PHMkeys, Pen Commander, Spb FullScreenKb, PDA MediaKb)
I've been all over the web, and I think I understand keystroke scan-codes and values... and how they work together. Is there something akin to an ASCII "value" for this key combination? (099/0A1; 073/081; 153/161)?
Any ideas are appreciated. I've no aversion to research or work, but can't figure out what to ask or where to look further.
(I just really need a more direct/reliable functionality to scroll entire screen at a time left/right.)
Thanks in advance if anyone can help.
Dell Axim x51v WM5 (if it matters)
(Please feel free to "re-direct"/re-locate/modify/enlighten etc.)
pro-fit2: your post sounds like one of the very few that truly does merit going in the developer forum Please repost it there.
BTW, the solution to your problem sounds like you could just emulate scrollbar commands, rather then keyboard commands. That's fairly easy to do by posting WM_VSCROLL or directly manipulating the scrollbars in code. With that you can emulate smooth scroll, line scroll and page scroll. I wrote an app that can do that, once upon a time.
V
Scroll bar control, accessing, WM_HSCROLL
Vijay, thank you for permission and input.
Before I go further, I like the sound of your suggestion, but my code background is primarily VBA thru Excel, from which I access some minor(?) "other" things like PrintDialog, or other MS Office apps...
I'm willing to work through the API(?) to access window scrollbar controls, WM_HSCROLL (etc), but I would need a more basic start. If it's easy to generate, I'd love to see some further detail on the approach you described.
Thanks either way,
Pro-Fit
pro-fit2: apologies for being an ass, but could you open a thread in the developers forum, and I'll paste some code in.
I would open it for you, but it's better if it's opened under your member ID.
To get you started, this is a not particularly good article on scrollbar functions in vb.net. It's not VBA, but should give you an idea.
There are two ways to control the scrolling -
method 1: by sending the scrollbar a rough command to scroll up/down/left/right one line or one page. [ WM_VSCROLL with SB_LINEDOWN/SB_PAGEDOWN ]
method 2: by sending specific thumbposition control commands, which will give you fine control over the scrollbar. Frankly, this is probably what you don't need as it requires you to interrogate the scrollbar and then react accordingly. You just need to emulate line up/down I think. Look into SetScrollInfo etc.
Again, apologies for being obtuse, but there's no point filling this thread with redundant info. But start here:
http://windowssdk.msdn.microsoft.com/en-us/library/ms674659(vs.80).aspx
Open the development thread and we'll continue
V
Guys and gals, I’ve finished transferring most (but still not all) of my past guides, articles and Bibles to the XDA-Wiki (http://wiki.xda-developers.com/ ). Don’t forget to check them out – I’m ABSOLUTELY sure you’ll find them VERY useful!!
Wow.... GREAT WORK! Nice to see all the "FAQ" stuff in one place. THANKS!!!!!!!!!!!!!!!!!!!!!!!!
Disabling Beep Noise
Thank you so much for the FAQ, one question though, I tried to disable the beep sound when initiating a call and followed the steps, apparently that still didn't disable the beep noise.
Any suggestions?
Found it
After playing around with the registry, I finally found how to make the beep go away when initializing a call.
HKEY_CURRENT_USER\ControlPanel\SoundCategories\CallStart\InitVol set to 0. At default it should be set to 2.
Guys and gals, I've just finished migrating my latest articles & Bibles from the last ~5 months into the Wiki (so far, I haven't had the time to do this).
VERY important: I use my own scripts to convert my HTML-based articles to PhpWiki (also using other, Web-based PhpWiki converters). Unfortunately, there're some constructs that I just can't convert (and don't have the time to manually adjust ALL the articles - remember, there are hundreds of them); for example, consequent rows separated by only one line feed. (With them, the rows aren't rendered separated.)
If you encounter cases like this and would like to read the original instead,
1. you can find almost all these articles in the General forum ( http://forum.xda-developers.com/forumdisplay.php?f=256 ) here; you can easily find them by just entering a, say, sentence to search for from my Wiki article, only searching for my nick and the General forum in the Advanced Search engine ( http://forum.xda-developers.com/search.php )
2. at the bottom of many of my articles, there's a "Cross-posted to" section. Just click the XDA-Devs link in there.
3. alternatively, you can also search my blog ( http://www.pocketpcmag.com/blogs/ )
I do hope you'll find my articles useful
nice! thanks for all your work
Holy, old-thread, batman!
Hey all,
I've been searching for techniques people use to make transparent controls. The problem with windows mobile is that windows always have the CLIPCHILDREN window style set. So you can't grab the contents of the parent window (in WM_ERASEBKGND for example) because it isn't there.
One technique would be to have the parent pass the handle of the background DC it uses to the child control but that involves having a memory DC around all the time. And if the child control is covering any sibling controls you'd be out of luck as well.
Another solution I've read about is to temporarily hide the child window so the parent window is forced to redraw the parts that would normally be obscured by the control. I personally do not like this approach. (the drawbacks are also discussed on some MS forum, i'm not allowed to post outside links yet, google for "Rounded Buttons : Does any one see any problems with this method" and you will find it)
So, there are ways to achieve what I'm looking for but they are far from optimal. Just wondering what everybody else is doing to achieve this.
The responses in that thread are pretty much spot on (funny to find I know over half the posters in that thread by reputation).
If you want to do this well, you really need to draw your own stuff, making a complete custom UI.
There is no proper way to do this in Windows Mobile (without runtime kernel patching, that is ).
Chainfire said:
The responses in that thread are pretty much spot on (funny to find I know over half the posters in that thread by reputation).
If you want to do this well, you really need to draw your own stuff, making a complete custom UI.
There is no proper way to do this in Windows Mobile (without runtime kernel patching, that is ).
Click to expand...
Click to collapse
What do you mean by "drawing your own stuff"? I am drawing everything myself now in all control i made using AlpheBlend() where needed. But that still doesn't resolve the background issue. Or are you referring to just drawing everything in a single WM_PAINT handler and only having one screen DC?
PegNosePete said:
What do you mean by "drawing your own stuff"? I am drawing everything myself now in all control i made using AlpheBlend() where needed. But that still doesn't resolve the background issue. Or are you referring to just drawing everything in a single WM_PAINT handler and only having one screen DC?
Click to expand...
Click to collapse
Well the method I use in my own new UI's is indeed per form (excluding WinAPI controls like edit boxes and such) draw using only one DC.
The problem is that any 'windowed' control, the parent will not draw to the DC if a 'windowed' control overlaps. Due to CLIPCHILDREN all data drawn to that position is simply lost.
Now, handling WM_PAINT you can get the entire update region, which tells you which parts of your form have to be redrawn. You must use this information, because blitting the entire form is very slow!
In essence, to do this right you well end up faking most of the GDI system, including your own 'fake' child windows, invalidating and revalidating portions, calculating the intersections of your 'fake' invalidated regions of the screen with the update region you get in WM_PAINT and redrawing those parts.
There are several different strategies to go about this, one is to redraw on demand, another one is to use double buffering.
I personally mostly use the double buffering technique, as this easily provides every 'fake' control with a bitmap of it's own region. A child control can then alphablend using the parent's buffer as one of the alphablend sources.
You can of course combine this with keeping state information whether a child, grandchild, etc is using alpha / transparency and this with an algorithm deciding which control needs double buffering or can draw on-demand, which can give both speed and memory use advantages. In a lot of situations you can then suffice with only double buffering the 'top' component (form) and a select number of child components.
Of course two drawbacks of per-control double buffering are speed and memory use. You can eliminate the complete-form double buffer with some smart coding and calculating. This will give you a slight speed and memory advantage. Memory use is high because many of your controls will have a copy of their current state.
This can be as complicated, feature-filled, fast and efficient as you are willing to make it. The better you can design the code the better it will work, but it is not a trivial task. There are many ways to go at this, no one way is definitely better than the other ways. It depends on what your applications does with it's display, how simple you are drawing (are you making a simple white background, or a background based on images for example gradient?), which method is more efficient.
The other method is getting the update region and actually perform redrawing of those invalidated sections (instead of copying from buffer). I can tell you from experience that if you are using image backgrounds and alphablend calls, this will be _much_ slower than double buffering (if done right).
I know all of this probaby makes little sense, I'm not a hero with explaining things ... you really have to figure this out for yourself, I guess.
Other advantages of building your own UI system are that if you do it smartly and buffering, it is very easy to port to directdraw, and possibly even GL. But I must warn you, on far the most devices actually using directdraw for this stuff is not much faster, it is in fact hardly noticable. If you manage to make a GL port, that can especially on older HTC devices (pre-HD2) be much faster.
*Anyone get the reference? Haha*
Resident Mort
The Scripter's Companion
Current News / Status:
Resident Mort is currently Under Development
Resident Mort is planned to be a background EXE that will extend the functionality of MortScript available to developers through the usage of the "PostMessage" function.
Resident Mort is planned to extend functionality by adding extra, possibly more complex, functions or even adding in the ability for more complex GUIs.
Features (Green = Implemented, Blue = In Testing, Orange = Planned, Red = Failed):
GetProcessList - Gets a list of Running Programs
GetRecentApps - Gets a list of Recent Apps (10)
CreateScript - Creates a MortScript with the provided info
MakeFile - Makes a file of any kind with the provided info
MakeFolder - Makes a folder at the specified location
RegToEvent - Registers a File to an event
UnRegFromEvent - Unregisters a File from an event
IsIdEventRegistered - Checks to see if a File is registered to an event.
DispImg - Displays an Image to the screen [and gets where the user Presses]
MakeForm - The Initial call for setting up an 'advanced GUI' form
FormAddObject -A Call that will add one of the predefined objects to the form being created
DeployForm - The Final call for setting up an 'advanced GUI' form, displays it to the user
This application is being made for MortScripters, to possibly make some projects easier. Since I don't use MortScript so much any more, I do rely on you the developers who use MortScript, to tell me what you want in the program.
Since I have a good deal of Functions there, I will commence work on a primary release
Saved For Future Use - Features and Screenshots
like the idea! advanced guis would be very useful
so this is a compiler? I am not sure what this is about
-sorry
No, this is a Resident App, an EXE that is always running in the background. It will have certain functions in it which can be accessed by MortScripters.
All the functions can be called with PostMessage ( I will provide documentation on how to do so, when I make a first release ). Then the results will either be written in the REGISTRY, written to a FILE, or copied to the CLIPBOARD (depending on how the scripter wants to handle the task).
Does this clarify it a bit?
Thanks for sharing!
A small update:
I am using this 'decent' planning utility, to help me keep track of my growing projects. According to this utility, the program is close to 30% complete. Then again, this is just a 'decent' utility haha. I would say, in my estimation (since some Code is "Copy + Paste"), I am close to 60% to 75% done.
A small change in my plans:
While I originally had the intentions of making this program as simple as a PostMessage in MortScript, I found out the following two Limitations:
1) MortScript's PostMessage/SendMessage only support(s) sending Numbers in the wParam and lParam parameters...very disheartening.
2) Due to #1, I made an assistant EXE, which would be run instead of calling PostMessage [this way I could do it Natively in my own control], but it is MUCH harder to transfer data between two applications that I would have thought! Due to Virtual Stacks and Memory Allocation 'rules', I couldn't EASILY do this.
So Here is my change:
In order to use Resident Mort, scripters will have to do about 3 or 4 commands to run. The only real commands that need to be used are PostMessage and RegWriteString (Did I get those right?).
In any case, my Resident Mort will read the Registry for corresponding wParam and lParam values and use those [in the future I will attempt Clipboard integration, to avoid Registry Interfacing].
When I release this program to the public, I will try to include a MortScript file that shows how to use all the functions. I don't remember much of MortScript [unfortunately], but I was thinking it could be helpful to make a "Library" of MortScript functions so a script will only have to call that function. But that is if some kind dev. would like to help out later on
Anyways, Thats that for this update. Expect a result in the coming week.
That sounds interesting for adv. gui functions.
Cyclonezephyrxz7 said:
1) MortScript's PostMessage/SendMessage only support(s) sending Numbers in the wParam and lParam parameters...very disheartening.
Click to expand...
Click to collapse
That's not MortScript's fault, it is design of whole Windows CE kernel, more here
I'd go with background EXE, that would listen to messages WM_USER+somenumber, maybe even region (for different actions, so you'd have both lParam and wParam free for another parameters). If you need help with this part, drop me PM on MSN, I had to study this a bit in the PinchToZoom project myself.
@OndraSter : Yeah, I know that Windows CE has limitations, however it is not impossible. Such an ability could be implemented in a code-update to MortScript. I did my reseach (if you look at #2, I mention that I found it much harder to transfer data between exe's that I had hoped) and found that you can transfer data via SendMessage (the Synchronous method) using a TRANSFERDATASTRUCT and WM_COPYDATA. If MortScripts interpreter could identify a SendMessage with a String value in either wParam or lParam, then it would create such a structure and transfer it, the receiving app would HAVE to take care of deleting the data though, or you have mis-used RAM.
As for how it is going to work now, I did not consider using WM_USER + a value, mainly because my program won't be using other Messages, and will only act if the correct wParam/lParam are provided (preventing accidental execution if the System decides to post a message with the same ID). I have it mostly covered, and I am closing in on finishing (currently with Reg data retrieval only, no Clipboard yet). I have completed 3 of the 7 Proposed Functions (MakeFile, MakeFolder, CreateScript) and I would have finished RegToEvents, but I got sorta lazy hehe. DispImg shouldn't take me more than a few minutes when I get to it, and once I get the API calls for Processes and figure out how to read the MRU reg-entry, I will have the last 3 complete!
As for Clipboard data retrieval, unless I am using the entirely wrong API calls, MortScript has an interesting way of using the Clipboard...I tried copying simple strings like "hello world" to the clipboard using MortScript, then trying to retrieve them in my Resident Mort, but the clipboard always comes up empty... Any ideas anyone?
Thats that for now I am about ready to release....any other functions you want implemented?
As for how it is going to work now, I did not consider using WM_USER + a value, mainly because my program won't be using other Messages, and will only act if the correct wParam/lParam are provided (preventing accidental execution if the System decides to post a message with the same ID).
Click to expand...
Click to collapse
http://msdn.microsoft.com/en-us/library/ms644947(v=VS.85).aspx
Good idea, the only downside being that it will generate the Message Numbers each time it is run... It is not assured that the Post / Send Message MsgIDs will remain constant.
Thanks for the link however
Cyclone,
Sorry about taking so long to post here...
How about, when the BT is on, this reports what is "out there" based on what the BT stack is telling you.
That is, it should read the surrounding area, then report that is saw my BT dongle. In the car, it should report that it saw my BT GPS unit.
Then, I can use that information to change my profile. That is, when it sees the BT dongle, regular phone calls. When it sees the BT GPS unit, run speaker mode, or connect to the GPS unit for phone calls.
Thanks!
--Ironhead
P.S. it would need to support the Touch Pro 2, Rhodium (my understanding is that it is Widcomm BT stack)
I"ll see what I can manage. I am really 'grid-locked' in my work on a couple of projects already So a release of this may have to wait a while....Sorry
I wish I had caught you a little sooner...
AutohotkeyCE may be a better base to work from than Mortscript...
http://www.autohotkey.net/~Micha/AutohotkeyCE/html/index.htm
In fact... AHKCE should be able to cater to all of your needs without the separate resident app
Yeah, I have seen that before. This project is really just a little challenge for myself to expand upon MortScript [because I know it is widely used].
Thank you for the link/suggestion however
I've been playing with Mortscripts for a while, I'm really thinking I can do everything I want, right from there...
EXCEPT:
Actually getting the information from the BT stack. I just need to see if there are any registered BT devices around my phone (so I can tell if I am in my car, at home, at work, etc.).
--Ironhead
Bumpity bump!
Hehe...Yeah, sorry for the lack of work on this. Check out FFP_LockScreen. I am working on a new release. I have very little time now, and I can't manage more than just one or two projects at a time. Once I release FFP_LS 3.0, I can devote some time MAYBE to this project. It all depends on how quickly the XDA-Marketplace idea takes off.
Sorry =\
I you can add a tool to make an GUI... it s must be soo cool...
Hi,
I already made some calender widgets and it worked fine so far. Now I want something new, but don't know how to do. Let me explain:
I would like to pick up the first day with calendar event and then list time1 and event1 for day1 followed by time2 and event2 for day1.
Then show next date/day with calender event and then list time1 and event1 for day2 followed by time2 and event2 for day2, then time3 and event3 for day two and so on.
I found no samples for a solution, but maybe one of you has an idea how to do this?
Thanks
Joern
I'm not sure I understand your intent correctly, but it sounds like you're just making a calendar with a list of the upcoming events, is that correct? I have a widget for that. I can't attach the .zw file (and for some reason, can't make a zip - I'll have to look into that), but here's my template: https://dl.dropboxusercontent.com/u/9467385/calendar-tron.zw
The way I have it structured is 6x Rich Text, 3 for event names, 3 for the times. Here's the text I entered for each.
Name #1: #C0TITLE# (that's a zero, not the letter O)
Time #1: #C0SHH:mm#-#C0EHH:mm# (that prints the start and end times)
For the following events, just change the 0 to 1 for the next, then 2 for the next, etc.
Hope this helps.