|
There are many keys. Is there any straight way of doing this?
|
|
|
|
|
|
Hello Everybody,
In our application we have added a Ribbon control with multiple tabs.
Is there anyway to select / change tabs through code? I can see an option available in C# (SelectedIndex), like that is there anything available in C++ also?
for eg, I am in 3rd tab in my application, and when I reset, first tab needs to be selected.
Thanks in advance.
Regards,
Gopinath.
|
|
|
|
|
You can set IsSelected to true on the RibbonTab you want to select.
modified 13-Sep-18 21:01pm.
|
|
|
|
|
Hi Thaddeus Jones,
Thanks for your reply.
I don't see any option like isSelected in RibbonControl tabs.
Can you give me a sample code if any, so that I will get some idea.
Regards,
Gopi.
|
|
|
|
|
|
Hi,
Thanks again.
Let me give this a try and let you know.
Regards,
Gopi.
|
|
|
|
|
Your answer is for the .NET Framework, but I think the OP's question is about native C++.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Because of the comparison with the C# version I expected it to be about the same control, but you may be right.
In the CMFCRibbonBar , tabs are called categories and they can be set with SetActiveCategory() .
modified 13-Sep-18 21:01pm.
|
|
|
|
|
I think, this will not work for my solution. Anyways, let me try.
|
|
|
|
|
Hi Richard,
Yes, you are right, its for C++ only.
Regards,
Gopi.
|
|
|
|
|
I have a code as below.
#include <ppltasks.h>
#include <iostream>
using namespace concurrency;
using namespace std;
int wmain()
{
auto t = create_task([]()
{
wcout << L"Task A" << endl;
return create_task([]()
{
wcout << L"Task B" << endl;
});
});
t.then([](task<void>& t3)
{
wcout << L"Task C" << endl;
t3.wait();
}).wait();
}
I expected the output to be
/* Output:
Task A
Task B
Task C
Task B
*/
But the output is
/* Output:
Task A
Task B
Task C
*/
Why t3.wait(); isn't calling the B task again or a tleast should throw error?
Jesus saves
|
|
|
|
|
That's the thing with parallelism, it never does what you expect.
|
|
|
|
|
why is the code giving error while compiling?
task<wstring> my_task()
{
auto s = make_shared<wstring>(L"First value");
return create_task([s] {
wcout << *s << endl;
*s = L"Second value";
return *s;
}).then([s] {
wcout << *s << endl;
*s = L"Third value";
return *s;
});
}
UPDATED
The error is as follows,
Quote: 1>c:\program files (x86)\microsoft visual studio 14.0\vc\include\ppltasks.h(372): error C2338: incorrect parameter type for the callable object in 'then'; consider _ExpectedParameterType or task<_ExpectedParameterType> (see below)
1> c:\program files (x86)\microsoft visual studio 14.0\vc\include\ppltasks.h(402): note: see reference to class template instantiation 'Concurrency::details::_FunctionTypeTraits<_Function,_ReturnType>' being compiled
1> with
1> [
1> _Function=my_task::<lambda_fe524192daf67b16ea75ab49971b7103>,
1> _ReturnType=std::wstring
1> ]
1> c:\vc++\concurrency_program\createtask\source.cpp(41): note: see reference to class template instantiation 'Concurrency::details::_ContinuationTypeTraits<my_task::<lambda_fe524192daf67b16ea75ab49971b7103>,_ReturnType>' being compiled
1> with
1> [
1> _ReturnType=std::wstring
1> ]
1>c:\vc++\concurrency_program\createtask\source.cpp(41): error C2440: 'return': cannot convert from 'Concurrency::task<concurrency::details::_badcontinuationparamtype>' to 'Concurrency::task<std::wstring>'
1> c:\vc++\concurrency_program\createtask\source.cpp(41): note: Constructor for class 'Concurrency::task<std::wstring>' is declared 'explicit'
I am just trying to understand ppl programing structure. Where as the following code compiles.
task<wstring> t1 = create_task([]() {
wprintf(L"create_task\n");
return wstring(L"create_task");
});
Jesus saves
modified 12-Jun-18 2:50am.
|
|
|
|
|
Daniel Ramnath wrote: why is the code giving error while compiling? Should we make an attempt at guessing the error?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Sorry, my description was not elaborate. I updated the error. But I found out the reason and posted it below.
Jesus saves
modified 12-Jun-18 2:56am.
|
|
|
|
|
This issue is solved when 'then' function call is parameterized as follows
task<wstring> my_task()
{
auto s = make_shared<wstring>(L"First value");
return create_task([s] {
wcout << *s << endl;
*s = L"Second value";
return *s;
}).then([](wstring s) {
wcout << s << endl;
s = L"Third value";
return s;
});
}
Jesus saves
modified 12-Jun-18 2:55am.
|
|
|
|
|
Hello, I'm trying to solve the 3 subset sum problem witch dynamic programming using a 3D array but I don't really now which rules to use to fill the array, can someone please help me to figure out the rules.
Example (I need 3 subsets such that they have same sum)
Input: {2,2,1,1}
A = {2}
B = {2}
C = {1,1}
Return: true
How I understand it: With 3D array I'm searching if I can find 2 Subsets with sum = TotalSum/3 each. But how to fill the array, which rules should I use
int subSetsFound(int n, int set[], int sum1, int sum2) {
int cuboid[sum1+1][sum2+1][n+1];
for (int i = 0; i <= n; i++) {
cuboid[0][0][i] = 1;
}
for (int i = 1; i <= sum1; i++) {
cuboid[i][0][0] = 0;
cuboid[0][i][0] = 0;
}
for (int i = 0; i <= sum1; i++) {
for (int j = 1; j <= sum2; j++) {
cuboid[0][j][i] = 0;
}
}
for (int i = 1; i <= sum1; i++) {
for (int j = 0; j <= sum2; j++) {
for (int k = 1; k <= n; k++) {
cuboid[i][j][k] = cuboid[i][j][k-1];
if (i - set[k-1] >= 0)
cuboid[i][j][k] = cuboid[i][j][k] || cuboid[ j-set[k-1] ] [j] [k-1];
}
}
}
return cuboid[sum1][sum2][n];
|
|
|
|
|
how InitInstance() is implimented internally
|
|
|
|
|
Open the file C:\Program Files (x86)\Microsoft Visual Studio <version>\VC\atlmfc\src\mfc\appcore.cpp.
|
|
|
|
|
I am working on an embedded product with an ARM-processor and I need to come up with an approach on how scheduling of tasks is going to work and then implement it. The following requirements apply:
• Standard C (no assembler).
• Can run on "any" microcontroller (of course, it needs to have a certain amount of RAM and flash).
• No use of malloc.
• If running on ARM and there's nothing to do and all timers are turned off, then it should enter stop mode (=system clock is turned off).
• If running on ARM and there's nothing to do but at least one timer is running, then it should enter sleep mode (=some peripherals are turned off, but the system clock and timers are still working).
• Needs to have some sort of prioritization, for example, low-level driver tasks needs to be handled before higher level tasks (such as tasks that arisen due to, for example, a push button pressed event) may be handled.
• It needs to, in some way, support calling of asynchronous functions, such as starting a DMA-transfer and then you get an interrupt when it's finished and in between it should execute other tasks.
My project is fairly limited in scope (not a lot things going on simultaneously), but I'm still struggling a bit to meet all the requirements. I will share below some of my thoughts. I was thinking of something like a modified round-robin scheduler with priorities with a number of queues:
void (*taskFunctionPtr_t)(uint32_t arg1, uint32_t arg2)
enum queueSelector_e {LOW_LEVEL_DRIVERS, USER_EVENTS};
addTaskToQueue(taskFunctionPtr_t, queueSelector_e);
In main.c:
while (TRUE) {
if (0 < numQueuedTasks(LOW_LEVEL_DRIVERS)) {
handleTask(LOW_LEVEL_DRIVERS);
continue;
}
if (0 < numQueuedTasks(USER_EVENTS)) {
handleTask(USER_EVENTS);
continue;
}
if (anyTimerRunning()) {
enterIdleMode(); } else {
enterStopMode(); }
}
In order to support asynchronous tasks, I probably need to make my tasks and queues more advanced:
void (*asynchronousTaskFinishedFunctionPtr)(asynchronousTaskResult_e);
void someAsynchronousFunction(asynchronousTaskFinishedFunctionPtr);
enum asyncTaskStatus_e {TASK_NOT_STARTED, TASK_IN_WAIT_PHASE, TASK_FINISHED_NEEDS_REPEAT_DUE_TO_ERROR, TASK_SUCCESSFULLY_FINISHED};
asyncTaskStatus_e (*getAsyncTaskStatusPtr)();
addSynchronousTaskToQueue(taskFunctionPtr_t, queueSelector_e);
addAsynchronousTaskToQueue(taskFunctionPtr_t, queueSelector_e, getAsyncTaskStatusPtr);
Then I'd have to have something like this in main.c:
while (TRUE) {
Bool_t taskIsInWaitPhase;
if (0 < numQueuedTasks(LOW_LEVEL_DRIVERS)) {
taskIsInWaitPhase = handleTask(LOW_LEVEL_DRIVERS);
if (!taskIsInWaitPhase) {
continue;
}
}
if (0 < numQueuedTasks(USER_EVENTS)) {
taskIsInWaitPhase = handleTask(USER_EVENTS);
if (!taskIsInWaitPhase) {
continue;
}
}
if (anyTimerRunning() || atLeastOneTaskInWaitPhase()) {
enterIdleMode(); } else {
enterStopMode(); }
}
Bool_t handleTask(queueSelector_e) {
if (taskIsAsynchronous()) {
if (asynchronousTaskStatus == TASK_SUCCESSFULLY_FINISHED) {
incrementTaskQueueReadPointer();
} else if ((asynchronousTaskStatus == TASK_NOT_STARTED) ||
(asynchronousTaskStatus == TASK_FINISHED_NEEDS_REPEAT_DUE_TO_ERROR)) {
callTaskFunction();
} else if (asynchronousTaskStatus == TASK_IN_WAIT_PHASE) {
return TRUE;
}
} else {
callTaskFunction();
incrementTaskQueueReadPointer();
}
return FALSE;
}
There are still issues with this approach, for example, how do I handle long tasks? I don't want a driver task to have to wait for a long user task to finish. I guess I need to have a requirement that all tasks need to be short and if they are long in reality, then they need to broken up and then the task will need to tell scheduler to repeat the same task:
void longTask(uint32_t arg1, uint32_t arg2) {
enum partSelector_e {
PART1,
PART2,
PART3,
PART4,
PART5
};
static partSelector_e partSelector = PART1;
switch (partSelector) {
case PART1:
do1stPartOfLongTask();
partSelector++;
repeatThisTask(); return;
case PART1:
do2ndPartOfLongTask();
partSelector++;
repeatThisTask(); return;
case PART3:
do3rdPartOfLongTask();
partSelector++;
repeatThisTask(); return;
case PART4:
do4thPartOfLongTask();
partSelector++;
repeatThisTask(); return;
case PART5:
do5thPartOfLongTask();
partSelector = PART1;
return;
}
}
Another problem is how asynchronuous calls can be handled. Let's say I want to do the following and the order of sequence is important:
void button1pressedTask(uint32_t arg1, uint32_t arg2) {
readADC(); setPinHigh(); startDMAtransfer writeI2Cdata(); writeUARTdata(); }
Remember, when calling an asynchronous function, other tasks should be allowed to execute. Does anybody have any suggestions how I can solve this? Am I on the right track or would someone suggest a completely different approach?
modified 10-Jun-18 13:47pm.
|
|
|
|
|
All of your code you have done is a co-operative system for the situation of longer tasks you need to do pre-emptive context switches and for the asynchronous order problem you need semaphores,mutex or spinlock implementation.
For pre-emptive context switching you usually have a timer interrupt it triggers 10-1000 times a second. When the interrupt triggers it looks to see what task should run next in a scheduler scheme, it then forcibly saves every cpu register and every fpu register to a context stack so the program can resume from that point. Next it loads the cpu registers and fpu registers for the next task to run from a context stack and then it proceeds to run that task until a subsequent timer tick stops it passing control to another task. You will require critical section process which is small areas of code when it enters the task switcher can not interrupt and often that is as simple as switching off interrupts so the timer interrupt doesn't fire.
Semaphores or spinlocks are the usual way of dealing with sharing the I/O functionality. So in your DMA example the use of the DMA would have an aquire and release process. So any function wanting to do a DMA transfer would first ask for ownership of the DMA, if the DMA is in use it will already be aquired and the caller must wait for whoever has it to release. So anyone that has the DMA then releases and the act of doing so then allows waiting callers to then execute so it looks like.
void DMA_Write ( /.* some variables */)
{
SpinLock_Acquire ();
ActualDMAFunction(/.* some variables */);
SpinLock_Release ();
}
For the processor you are on if you search for "ARM Synchronization Primitives" and ARM will have a whitepaper on typical setups and minimum requirements. It will usually involve the use of the special opcodes LDREX/STREX (as well as WFE/WFI on multicore systems if you want to sleep the core while waiting).
You will also find the code for the context switch by a simple search of "ARM Context switch" with the processor name and you will get an ARM white paper describing it. They will all generally work on entering the call with one register pointing to the where to save all the current registers and another to where to load the registers from.
There are some really simple AVR task switcher projects which would be easy to adapt .. you simply need to change the context_switch assembler and replace the ATOMIC_BLOCK store and release with the interrupt enable/disable (it is all it generally does on smaller AVR processors) it is a basic CRITICAL SECTION control so it doesn't get interruptted with the code inside the curly brackets.
GitHub - kcuzner/kos-avr: Kevin's RTOS for AVR microcontrollers[^]
That is basically one file kos.c and 1 header kos.h
That uses a simple round robin scheduler (every task has same priority) if you want advanced priority based scheduler you can simply replace the scheduler code but I would suggest get the most simple running first then add the advanced scheduler. All you will end up doing is replacing the scheduler function with a more advanced one and your task creation call will have a priority you assign.
Final note if you are on a multicore system you will need to change the semaphore to the proper arm code the presented one generally won't work with multicores. It should be fine on a single core.
If you need further help we really need what ARM processor.
In vino veritas
modified 11-Jun-18 0:54am.
|
|
|
|
|
How is this different from using an off-the-shelf RTOS such as FreeRTOS?
|
|
|
|
|
It's similar if you look only at the very basic Kernel but things can be much more complex, painful and they may already have known problems
Some examples
1.) ARM Security/protection ring system usually at least two levels EL0 and EL1 and possibly EL2 & EL3 on an ARM8.
As an example FreeRTOS was not designed with those in mind, none of the existing ports will utilize the scheme with any intelligence.
2.) Multicore support on ARM cpus like ARM7 & ARM8.
You usually have to bring the MMU up to get cache coherency and that often means memory virtualization will need to be operating. For example on Free-RTOS I know of only a simple SMP port on a multicore system, no AMP and no BMP implementations. So FreeRTOS was not designed in an era with multicore support in mind.
3.) Multiple implementations which adds a whole complexity as your implementation becomes one of x number and not the most efficient or best suited to your CPU. You may struggle with massive code complexity on code that may not even compile in your implementation
If you are on a multicore cpu like a cortex-a53 points 1 & 2 will probably cause you a great deal of problem. That is why there are no real fully functional ports of Free-RTOS on things like Raspberry Pi 3 and beagle board blacks (there are a couple of half functional ports). So Free-RTOS is easy to port for simple single CPU it is harder to port and often at odds with how you want to operate complex multicore CPU's. Hence we come back to the problem what CPU are you talking about?
I would also add FreeRTOS has some obvious shortcomings of features you may like, like no concept of task aging etc (Aging (scheduling) - Wikipedia[^]
As with everything you are better of playing and working out what is a good system rather than mindlessly porting some system and not understanding it properly. So I might for example port FreeRTOS on a simple ARM5 or 6 cpu but I wouldn't bother about it on an ARM8 the later being far to different for what Free-RTOS was designed around.
Again I say if we know what CPU we are dealing with it is easier to make more detailed and helpful suggestions.
In vino veritas
modified 11-Jun-18 9:02am.
|
|
|
|
|
leon de boer wrote: Again I say if we know what CPU we are dealing with it is easier to make more detailed and helpful suggestions.
Single core (STM32F4 and STM32F7). Since I'm working with rather basic microcontrollers and my applications really aren't that heavy, it's seems a bit overkill to do the context switching like an RTOS would do.
modified 11-Jun-18 9:21am.
|
|
|
|